@Named versus @Model - CDI vs/and ManagedBean

Question

I was wondering about this article explaining the direct access of EJB from JSF : http://www.mastertheboss.com/cdi/context-dependency-injection-with-jboss-weld

I do understand, that with CDI you can inject and access every bean type, including entity beans from the far end of the layer tier.

However.

[Question 1]: Should I discard the @Model controller and only apply @Named to all the classes? This kind of abandons the approach of having JSF --> ManagedBean--> EJB --> EntityBean to JSF --> EJB --> EntityBean. I just have the feeling this extra ManagedBean is causing me an extra layer without not much benefit.

[Question 2]: In what cases would you still want to maintain that extra Controller layer?

thanks

Answer 1

The best way to get the most from the overall platform is to use CDI as your controller layer (receiving requests from the JSF based frontend) and delegating internally to EJBs or other CDI beans for business logic. I would not use JSF ManagedBeans as the concept is deprecated in Java EE 7, in favor of the CDI programming model.

The controller can be used to always convert data types, separating out your front end and back end models.

Answer 2

I don't think that there is a universal answer. It depends on your controller, both are valid arquitectures.

The key is whether your controller requires services offered by the container.

For example if your controller should execute outside a transaction then justifies the extra layer.

However, always tend towards simplicity if you can. If your application is simple enough to have just the three layers then don't over complicate it.

As far as replacing @Model for @Named goes, @Model is just a shortcut for a @RequestScoped @Named bean. Only replace @Model for @Named if you want the bean to have some other scope.

Answer 3

I think the equation should be:

JSF = View (.xhtml) + Controller (ManagedBean)
EJB = Model

There's no skipping to go directly from View to Model unless you're putting the whole back-end logic inside a ManagedBean, which is obviously not a good practice.