4

I want to clearly understand the proper way of developing a JSF application. In our project, the model and controller is the same class, represented by CDI bean. I'm sort of confused whether it's a good practice. As far as I understand MVC pattern, the controller should handle user actions (such as submitting form) and the model should contain business logic and data. Or is it OK, that they are in the same class?
Also, should every page have its own separate Controller/Model (i.e is it considered a good practice)?

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
jFrenetic
  • 5,384
  • 5
  • 42
  • 67
  • 1
    Related: http://stackoverflow.com/questions/5104094/what-components-are-mvc-in-jsf-mvc-framework – BalusC Aug 14 '11 at 22:42

2 Answers2

6

It is generally a better idea to have two layers - one with JSF managed beans (might be managed by CDI) and another one with beans that are agnostic of the web framework that is using them.

As for the "controller" - the FacesServlet can be viewed as the "front controller" for the entire application.

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
  • Having troubles, to translate your approach to MVC. So, managed beans represent **Model**, but what is the second layer for? And is it fine to have just one `Front controller` for the entire application, or should I create separate controller for each page? Thanks! – jFrenetic Aug 14 '11 at 19:52
  • If your beans have no dependency on JSF or on the servlet API then it is fine to have only one layer. But if they interact with the web stuff, like getting the faces context or setting response headers, then it is not pure business logic, and should be separated – Bozho Aug 14 '11 at 20:01
  • I Agree, if you use full J2EE stack, you can keep the session in @SessionScoped JSF managed beans and have your stateless EJB's acts as DAO's or business logic implementation. – Kris Aug 16 '11 at 19:08
4

JSF controllers are just UI handlers, they shouldn't carry any business logic. Usually there are even more layers (I include here only layers that relate to logic):

  1. UI Controller - that is tightly tied to the UI and thus to the technology you use for MVC
  2. Service Layer - is a facade-entry point to the business logic, usually also manages transactions and in some cases - DTO/Entity transformation if this is required. It doesn't know anything about Web MVC technology you use.
  3. Business logic that obeys Domain Model pattern (sometimes called Domain Service).
Stanislav Bashkyrtsev
  • 14,470
  • 7
  • 42
  • 45
  • Wow, that's a great answer for the first post! We definitely have all the layers that you described here, but it just seems to me, that some of them go beyond the scope of MVC pattern. I'm not sure, but I guess that the model sometimes serves as a delegate, calling the services that don't fit into Model-View-Controller pattern. – jFrenetic Aug 14 '11 at 21:19
  • Definitely it goes beyond. From different height there might be different patterns. So MVC cares only about 3 elements: View (xhtml), Conroller and a Model (which is a source of data to the View). Service Layer is something that is not covered by MVC, it's a separate EE pattern and it works in different part of a project. – Stanislav Bashkyrtsev Aug 14 '11 at 21:27