4

i'm developing a project using JSF 2 and JPA 2 (EclipseLink 2.3). In JSF 2 I learned that we must separate the Model from Controller and the same thing to the View (thanks BalusC). But now with the POJO's generated from JPA, I wonder if the bean, the model, it should be the pojos now.

My view is gonna be my .xhtml pages, developed in JSF 2.0, that will interact with my controllers then in controllers call the DAO's classes and then operate in my database.

Is this right ? I mean in the concept of MVC ? I want to do everything right, any tip ?

Thanks in advance.

Valter Silva
  • 16,446
  • 52
  • 137
  • 218
  • Hi Valter. What do you mean when you say "I wonder if the bean, the model, it should be the pojos now."? From the way I've seen JSF the pages interact with beans which can call Service classes which then interact with DAO classes. The domain objects could be manipulated in the beans directly or become part of a more complex model to fit the view. – James P. Sep 04 '11 at 22:10
  • Hi James, what i mean it was that if the POJO should work as the ManageBeans does before with jsf only. – Valter Silva Sep 04 '11 at 22:20
  • I'm not familiar with ManageBeans. I would say that the POJOs/Entities can be used as a basis for the model in the MVC sense. – James P. Sep 04 '11 at 22:31

3 Answers3

6

"MVC" has in JSF multiple points of view. From the high level view, the Model is represented by EJB/JPA and eventually DAO/DTO (if any). The View is represented by your own JSF code (which consits of managed beans and Facelets templates). The Controller is represented by the FacesServlet.

From low level view (a further subdivision of the high level View), the Model is represented by entities or DTOs. The View is represented by your Facelets templates. The Controller is represented by your managed bean. It's basically a M(MVC)C.

Note that "POJO" is a rather legacy term from the old J2EE/Hibernate times. Nowadays, with Java EE/JPA, they're called "Entities". Yes, it are those @Entity Javabeans. Als note that some may opt to use plain vanilla DTOs instead of entities which should decouple your JSF code from the service layer. JSF should then use those DTOs as model and the service layer should in turn map between those DTOs and the real entities. This is in my opinion not necessary. EJB3/JPA2 is a pretty slick API which already minimizes a lot of boilerplate code for which you would have used DAOs/DTOs like as in old J2EE ages. With Java EE 6 and higher, there's not really a need to be able to switch of service layer to for example Spring. Everything is already well thought out and standardized.

See also:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • 1
    In general, I'd just stick to pure Java EE 6 API and keep the code as simple as possible without too much layers and mapping/duplicating. This may sound a bit controversial to others, but why would you in the future ever choose anything else than whatever is already been provided by the Java EE 6 standard? In the past, this was different. There was no single standard. All 3rd party frameworks had their own way of approaching things. This is then abstracted away by some extra layer. – BalusC Sep 04 '11 at 22:46
  • "The Controller is represented by the FacesServlet." Nice of you to spell this out clearly (it confirms some of my thoughts). About the model in the MVC sense, are you aware of any applications which have a view-specific model that incorporate Entities/DTOs? I mean, besides pulling information from Entities it might be necessary to make something more complex from them or add data which is only used in the view (like the state of components in a sort of control panel GUI). – James P. Sep 04 '11 at 22:57
  • 1
    @BalusC,Thanks by the explanation (I would like to call you 'professor' because you (and the stack) teached me a lot about good pratices, coding in the right concepts (i already saw a lot of mess in codes before)), thank you 'professor', have a nice sunday =] – Valter Silva Sep 04 '11 at 22:58
1

Not completely right. It's usally better to avoid referencing model objects directly in the view; you can substitute them with DTO(data transfer object) that just serve the purpose of containing the data to be displayed

Simone
  • 2,261
  • 2
  • 19
  • 27
  • How are DTOs constructed? I'm curious about this as I've seen a few architectures mention DTOs. I imagine their role is to limit dependencies to the domain model. – James P. Sep 04 '11 at 22:12
  • They are simply beans with getter and setter but they don't implement any logic at all. In this case they would be constructed and populated by the model(the services in a usual enterprise application) after the model read data from db using dao – Simone Sep 04 '11 at 22:17
  • @Simone, but using DTO, I would duplicate my code ? I mean, I create a ManageBean to reference a Entity, is that right ? – Valter Silva Sep 04 '11 at 22:17
  • in your case the managebean would be the DTOs; there is a few duplicated logic but serve the purpose of decoupling the variuos layer of the application – Simone Sep 04 '11 at 22:19
  • @Simone: The way I've learned things is to use anemic (just attributes+ getters and setters) classes in the domain model. These classes are used by DAOs which pass them on to Services classes. Would a DTO fit in as being output from a Service method? Does the code shown on the following page look like a good practice? http://www.mistra.fr/tutoriel-jee-pgejeev2/tutoriel-jee-pgejeev2-dto.html – James P. Sep 04 '11 at 22:23
  • 1
    @James This is not wrong, but i would prefer the DAOs to return actual model objects, the one you directly use with an ORM for example. And i would prefer the DTO to be returned from services to controller and then to the view. But this is not wrong, because actually various different DTOs can be used through different layers, it's only a pattern – Simone Sep 04 '11 at 22:31
  • So, the correct way would be: first my pages (view), then call my facelets templates (controller) then i call DAO/DTO (Model), so then i operate in my database, is this right Simone ? – Valter Silva Sep 04 '11 at 22:48
  • well yes, if you don't have the additional services layer – Simone Sep 04 '11 at 22:49
1

Well, in my opinion, this is not correct. The XHTML pages is the view, but the controller is the JSF servlet (already provided by the framework) and what you call "controller" is actually the model (the business logic). The JPA POJOS are part of the model (the data model).

From the View you should invoke the business logic to obtain the result (as JPA Pojos) and use directly them (no transformation to DTO needed in your architecture) in the view.

Inside your model, you can organice the business logic as you whish (if you think that you need a DAO layer, very common in the industry, you can just put it).

Mr.Eddart
  • 10,050
  • 13
  • 49
  • 77
  • Hi edutesoy, i think the point view of BalusC and Bozho here http://stackoverflow.com/questions/2100115/i-found-jpa-or-alike-dont-encourage-dao-pattern are correct, whenk you use the MVC is much more easy to abstract your logic, you only need to worry with the DAO. – Valter Silva Sep 04 '11 at 22:51