0

I am developing a java web application and am trying to follow some patterns like dao/dto. At the moment i am thinking about such base architecture layers: scheme

I ran into some questions regarding the layers. The scheme would go as such: DAO takes in DTO and returns objects(entities) from DataBase, Service layer also takes in DTO, uses DAO and does all the required logic with the returned objects. UI Bean, Service, DAO and DTO classes are Entity specific - each entity has its own layers.

  1. Now would i need the UI bean to use in views or would that be an overkill and UI views can directly use service classes as ui beans? If no, why would i need UI bean?

  2. Another question is regarding DTO. I have created entities with all the required properties and as i understand DTO classes are like reflections of Entity classes. So why would i need these DTO classes and if i use them i recon it would require some converting from entity to dto and vice versa. Do i do the converting in Service layer? Would views (for eg. html pages) also display DTO object properties not actual Entities (as in calling #{UIBean.entityProperty})?

Community
  • 1
  • 1
eight
  • 339
  • 1
  • 5
  • 16
  • Thanks, but that does not answer my questions. I'm asking about the need of extra (UI bean) layer as an addition to Service and DAO layers. Also if DTO is needed or can i go with Entity classes since DTO classes reflects Entity classes and it would require converting between DTO and Entity object. I'm thinking about using DTOs because i've heard people saying exposing Entities to UI and Services is bad practice and you have to have some kind of DTO. – eight Dec 20 '15 at 18:45
  • It is all in there I think, also read related posts… – Kukeltje Dec 20 '15 at 18:49

3 Answers3

0

First of all, I would use the DTO beans on the front-end part only, but since u already mention UI-beans, i suppose these will do the trick just fine, the facade uses these to pass them to the controller for displaying your web-components. in between the Service and the facade you map the entities of the backend towards dto-beans. In this way your front-end will be completely loosely coupled to your backend.

Regarding your 2nd question I would like to point out an exact valable reason why your UI should always use dto or view beans. You can combine several backend entity-beans into one dto bean for easier processing on the front-end.

In general I keep always in mind DTO's for public acces, eta a web-service exposing it or a web-front end or a swing app, or... Entity classes only used in dao and service layer never further up.

Yoeri Smets
  • 142
  • 1
  • 9
0

As rule of thumb try to divide logical layers according to your context. Inspire you of the theory but use it with care. I give you my humble understanding of layer's interest with few examples. This vision is of course not complete but I hope it will help you to answer your questions.

  1. So is it overkill to use UIBean instead of Service DTO ? I would say it depends of your context.

Maybe there are user inputs data inside your UI beans ? You have to validate them with JSR 303 annotations for example. If those annotations have a meaning in this layer they are useless for underneath layers. That's why you will have a UIBean with JSR 303 annotations and a DTOBean without JSR 303 annotations.

But if they are exactly the same why duplicate ? Maybe at UIBean layer a date could be represented as a String type and you want to manipulate Date type instead of String at DTO layer. That's why you need to adapt your data between layers to work with objects that make sense to a particular layer. For example, you could add a BOAdapter (between UIView and Service) and DTOAdapter (between Service and DAO). Those adapters are usefull for transforming your data inside each POJO's format. For example, you could have in your BO(=UIBean) a date expressed inside three strings and you want a Date object for DTO so you transform it inside the BOAdapter:

public class BOAdapter(){
   private BOAdapter(){}
   public static DTO toDTO(BO objectBO){
      DTO objectDTO = new DTO();
      SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-aa");
      objectDTO.setDate(df.parse(objectBO.getYear()+"-"+objectBO.getMonth()+"-"+objectBO.getDay());
      [...]
}
}
  1. Why I need DTOAdapter ? Maybe you have a database that contains at least two tables Customers and Adresses with an integrity constraint between them. JPA will automatically generate the right code. But do you really need all this code up to UIView ? I mean if the functionnality you are coding needs only the name, surname and date of birth of your customer, their adress is useless. Again that's why you need to adapt your data between layers to work with objects that make sense to a particular layer. In this case you could create a DTO object only with name, surname and date of birth information and create a method inside your DTOadapter to transform your custom DTO into an heavy JPA object to work properly with database.

But I need the whole entity for coding my fonctionnality ? Maybe you need to add validation constraints inside this layer besides JSR 303. So it could be interesting to have DTO classes besides your entity for the same reason as BO objects.

But my entity is big how duplicate it easily ? Try to use a tool to map data (like dozer) automatically. If it is not too big do it manually.

Aurelien
  • 458
  • 1
  • 5
  • 13
0

Since you have Spring tag,

I will replace your [DAO] with Spring Data Repository. So most of the time, you write interface method / @query annotation, Spring Data write implement.

Replace DTO with JPA Entity. So I could use some reverse engineering.

[UI Bean] will most be composite of JPA Entity. With some validation

Thang Hoang
  • 250
  • 5
  • 22