CODEWITHSUNDEEP
javaspringhibernatespring-mvcspring-boot
Ramakrishna
Ramakrishna

Reputation: 426

Is it good that we link dao entity classes with mvc form

I am learning hibernate with spring. While implementing i am creating entity class like below 

@Entity
@Table(name = "USER_DETAILS", uniqueConstraints = @UniqueConstraint(columnNames = "USER_ID"))
public class UserInfo implements Serializable {


    private static final long serialVersionUID = 1L;

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "USER_KEY", unique = true, nullable = false)
    private Long userKey;

    @Column(name = "USER_ID", unique = true, nullable = false)
    private String userId;

//getters and setters
}

And i am designing a html page to get above input from user. As per the tutorial they are creating a DTO class with same variables which are in the DAO entity class and implementing JSR303 validation after that attaching that DTO to the form like below.

<sf:form action="/addUser" commandName="userDTO"
                method="post">
//input text boxes

</sf:form>

Its difficult to understand why we need to create a same DAO Entity class again without hibernate annotations and the same variables in the name of DTO. Please share some guidelines.

Is it a best practice or is it any performance / structural reason that we need to create DTO class for html form.

What will happen if we directly attach DAO entity class with form.

Please give some ideas / guidelines.

Upvotes: 0

Views: 683

Answers (3)

Nidhi257
Nidhi257

Reputation: 967

The simple answer to this question:

consider an example:

To get a summary of customer orders, That would have each row be taken from entities such as customers, addresses, products, orders etc. In such a case it is wasteful and slow to load all the entities to memory to render them in the flat search results screen.

Now, whenever the view changes it's not possible to change the entities(it will be time-consuming) but DTOs can be updated or deleted easily when as they are only used to fetch data and render them.

It is strongly recommended putting as much business logic into entities and try to have all the code which creates and connects entities default/package protected and as hidden as possible. When you do that you get the better OO design. An example would be the Order entity has a method getOrderItems to list the OrderItem entities but a protected setOrderItems method. The client would invoke a public method on the Order called addItem which took all the fields needed to construct the OrderItem entry internally using a protected constructor and add it into its list of order items. The Order becomes a "root/aggregate entity" which manages the relations and business logic of subordinate entities. This is a more naturally OO design than having "behaviourless" DTOs with the business logic entirely in service classes; or worse spread out across UI code. Have the service classes that query and load root entities then call method on the root entities that contain the business logic. That way different service class methods that work with the same root entities won't duplicate logic as the logic will be within the entities that are shared.

In simple words: If your entities are dumb with no logic then they are just DTOs.

Upvotes: 1

xyz
xyz

Reputation: 5407

For simple application like pet application you can use entity for web layer. The first problems came when you add N-to-Many relation in your entity model.

  1. Hibernate use interfaces list Set , but with it's own implementation like PersistentSet that has keep information about hibernate session, also you web part /level should has hibernate jar to work with this implementation of set :)

  2. Lazy loading. if you close hibenate session you will get LazyInitializationException , you avoid this you should keep your hib session open till you not finish work with entity in web level

Upvotes: 1

Mykola Yashchenko
Mykola Yashchenko

Reputation: 5361

In my opinion it's bad that we link dao entity classes with mvc form.

It's a better idea to segregate your application to some layers. The most usual approach is to have 3 layers: persistence, service and presentation layers.

Typically, each layer uses its own kind of objects:

  • persistence: repositories, entities
  • business: services, domain objects
  • presentation: controllers, DTOs

We need this because we want each layer to be separated from the other layers. If you want to use entities in your controller, your presentation would depend on how your data is stored. It's really bad. It shouldn't even know that or how data is stored.

Upvotes: 0

Related Questions