This question already has answers here:
What components are MVC in JSF MVC framework?
(4 answers)
Contradictory explanations of MVC in JSF
(1 answer)
JSF Controller, Service and DAO
(2 answers)
How to choose the right bean scope?
(2 answers)
Closed 5 months ago.
As the complexity of the web projects that I am working on increases, the need to include a MVC structure is becoming more urgent. My model classes are well defined, but view and controller code tends to get munged together. I've been using pretty heavy AJAX on the site also (RichFaces jsFunctions mostly) which makes things slightly more complicated.
Has anyone found good strategies for implementing MVC using JSF2? I do not want to introduce another framework to the project (e.g. Spring MVC).
Some ideas thus far, which I haven't started doing yet
For a page with heavy ajax, have a 'view' bean for remembering selected tabs, selected items, providing filtered lists of data, etc...
Have a 'controller' bean to handle actions such as changes to the model
Have 'command' beans which go between the JSF page and controller. A jsFunction populates the command bean with parameters, and calling command.execute() causes the command bean to call the correct method on the controller bean to perform the action. The 'command' bean may include some javascript to be called on completion. It may also specify regions of the page to be re-rendered.
Any thoughts?
Edit
What I see pretty often are managed beans that tend to do everything: keep track of users' selections, update the model, get filtered lists, etc...
We're using JSF 1.2 at the moment and so we can't use actions/actionlisteners with parameters. So for example, our managed beans contain variables such as m_selectedDate whose only purpose is to feed the selected date to the back-end on the call to updateFilteredItemsBasedOnDate(). It would be nice if the extra variables could go away since they are just temporary. JSF 2's EL with parameters should help but I'm curious if there is an alternate solution available.
I am curious if there is a way to apply MVC to managed beans, or some method of separating concerns so that we don't end up with large beans that try to do everything.
Are you looking for design patterns? If you are looking for MVC then BalusC answer is sufficient, else check this
https://web.archive.org/web/20171228073050/https://www.allapplabs.com/j2ee_design_patterns/j2ee_design_patterns.htm
Also check out this
Well, maybe what you need is a layered architecture. So far a MVC architecure, there are more concerns.
For example, you could layer you architecure in View, Business Logic and DataAccess layers, implemeting most of commons design and enterprise patterns in each layer.
You h've started whit one of them implementing MVC, but, is a good practice take in count "separation of concerns"
In this way you could achieve a well organized and decoupled code.
I hoppe this brief explanation was useful.
Regards.
You have to see the better way of managing the beans rather look into how better use the MVC in JSF. Because JSF itself come with the MVC in better implementation. I am not sure what exactly here you mean as the better way of implementing the MVC.
As Balusc told in the comments, JSF itself has the sufficient MVC for your application. May be if you want to separate the concerns, it is good idea to separate the business logic into Helper classes and write only the presentation logic in the beans.
There is debate on whether to use the bean for business logic or should separate it from the managed bean. That is all depends on the your application and domain specific.
Thanks,
Krishna
Related
Sorry for potentially a silly question - but is it acceptable with Spring to create a one dedicated service, let's say ServiceFacade, inject 20-30 other services into it and then pass such a ServiceFacade reference as a parameter to different business logic? Will such approach lead to issues within the application?
Yes, it is possible, Spring will correctly handle a bean with 20-30 other dependencies. However it is discouraged from a design point of view. Instead of one ServiceFacade you might have multiple facades, each with manageable number of dependencies, e.g. 5 and a factory returning different facades instances.
I am developing a Spring MVC web application and I keeps JPA entities in repository package, dao's and controller classes in separate packages with jsp's in a folder in WEB-INF.
My question is, in this app, what is the model, what is the controller and what is the view? Where should I keep the business logic (dao or controller)? What is the best practice in terms of clear separation of business logic?
For what you are describing, the layers are as follow :
view : JSP files
controller : the DispatcherServlet (front controller) and you controller classes
model : all what remains
For the latter part of your question, you are in fact asking for opinion based answers. But the following seems to be a common pattern :
If you put business logic in controller you get a Fat Stupid Ugly Controller (just google around). Even if Spring MVC gives you tools to test controllers, the common usage is to avoid it, because the controller is heavily dependent on framework, and it is best to make business logic as independent as possible of framework. One never knows, you may have to use a different framework later for any reason.
It is equally bad to put business logic in DAO for same reason : framework independance.
My advice is to add a service layer between controller and DAO, with a possibility of exception for a true CRUD application. It is a layer with less framework dependance ; and in fact the reason why it is generally not produced by framework : the framework cannot know your business logic. There's another reason for the service class, it is the layer where transaction demarcation should live : controllers hardly support JDK proxying (which is the default transaction demarcation in Spring framework), and it can be relevant to call more than one DAO method in one single transaction.
But I must admit that the above is my opinion and not the big truth (well not only mine, but definitely an opinon). You can certainly find use cases where business logic is so tiny that it does not require the overhead or a service layer : it is just an architectural choice, and provided you know why you make the choice any possibility can be good.
I am using Spring and JSF2 a lot and was wondering what the best way to integrate them is? Now i understand there are basically two ways to do this, but i have some problems with both:
a) Use normal #ManagedBean, and inject Spring-Services into that beans using #ManagedProperty: The problem is that i can't use Spring-AOP inside a #ManagedBean obviously, because it is not Spring-managed. I usually use an arround-aspect on every method annotated with my custom annotation #DatabaseOperation. Another example would be #Secured from Spring-Security and so on. I use a lot of AOP in my project and not beeing able to use them on "the top level" is really limiting for me.
b) Use SpringBeanFacesELResolver to make everything managed by Spring. On the pro side is that AOP works like a charm, but the cons are big too:
No ViewScope. I am not sure if i can trust custom view scope implementations like this https://github.com/michail-nikolaev/primefaces-spring-scopes on productive systems?
Serialization is not possible. It's already pretty complicated, but once i use AOP i can't get it to work because org.springframework.aop.aspectj.AspectJPointcutAdvisor is not Serializable
So my question is: How do you overcome this issues? How do YOU integrate JSF2 and Spring3.x? I have been using possibility b) mostly, but on my next project i need session replication..
Any further suggestions?
The main integration pain point of the two frameworks is that JSF is usually used in a stateful way. to make the integration the most seamless, you would have to let Spring handle the statefulness and page navigations aspects himself instead of JSF, as well as bean creation and scoping.
The second important integration point is at the level of the view expression language. We want to be able to access spring beans while building the view, which means the managed bean layer is no longer needed.
The best integration available for the two frameworks is provided by introducing Spring webflow, see here for further details. With SWF, JSF no longer manages beans itself, this is done by Spring. JSF does not manage page navigation anymore, this handled in the SWF flow definition.
Also the statefulness is handled by SWF. The flow definition XML file replaces large parts of the faces-config.xml for view navigation, transition actions, bean definition, etc.
Using the SWF JSF integration means that your faces-config.xml is mostly empty. Expression language accessing directly spring beans can be used while building the view, and a view scope is available.
If you want to keep a page isolated from the rest of the application, youcan create a flow with a single view state and self-transitions. An advantage of SWF is that it prevents duplicate form submissions via a POST-REDIRECT-GET mechanism that works transparently out of the box.
I've inherited an incomplete but small web project (Java EE 5, running on WebSphere 7).
The project consists mostly of JSPs that are accessed directly via their URL, and most JSPs look up their own reference to the EJBs (services) they need. Also, there's a Servlet for every form that gets submitted by the HTML code in the JSPs.
Architecturally speaking, is there anything wrong with this?
I was thinking it would be better to have an MVC design. I don't want to convert everything to JSF because I don't want to convert all the HTML and embedded Java scriptlets into JSF tags and managed beans.
I don't really want to use Struts or Spring MVC because they're not part of the Java EE 5 toolkit that comes out of the box with WebSphere, and I don't want to add additional complexity with the additional libs and config files.
I was thinking about building my own little MVC with a "ControllerServlet" that accepts a command and dynamically build and execute the command object, and redirect to the JSP view.
But I ask myself again, is there anything "wrong" with JSPs that post to Servlets? It's actually kind of elegant in its simplicity.
What do you think?
Any suggestions are GREATLY appreciated! Rob
You're asking a rather subjective/localized question. But ala.
There's technically nothing wrong with individual JSPs that submit to individual servlets. The only real problem is when the servlets turn out to contain duplicated code for quite common tasks like collecting request parameters, converting/validating them, setting bean properties, invoking actions, performing navigation. That is not DRY and is what a MVC framework with a single front controller and a well definied lifecycle is supposed to solve.
Or, if the servlet's tasks are actually well refactored with homegrown code to perform those common tasks, then this is in turn not very maintainable as no one else than the original developer knows the ins and outs of this custom framework. So it's hard to find anyone else willing to maintain this webapp without learning another framework again which the new developer wouldn't likely to see in other future webapps. That is why companies usually adopt an existing and well-developed MVC framework like JSF, Spring MVC, Stripes, Struts, etc.
I am looking for a good tutorial on migrating from struts to spring. I have multiple struts actions that I would like to refactor into spring components.
Here's one (assuming you're talking about Struts 1, although you don't specify).
Not sure how helpful it will be; depending on how clean the original Struts code was it could be relatively straight-forward, or brutal.
In my experience the bulk of the work lies in the JSPs, not the actions themselves, particularly if the S1 code made extensive use of the Struts tags. The actions themselves are easier to deal with because of strong IDE support.