I don't want to debate whether or not to undertake the conversion from struts2 -> SpringMVC. I have the best reason to do it. It is what the customer is asking/paying for.
I've done struts1 years back and I've done SpringMVC. I'm hoping to configure via xml and not use Annotations that much.
My plan is to:
Take each struts2 action class, understand what action is taking place and then create a clean API for delegating to the business layer. This step is not required. It is here so we can refactor whatever makes sense.
Create a SpringMVC Controller (roughly) for every struts 2 action class.
I know that is just touching the surface of what needs to be done. Anyone have anything else to add?
Thanks in advance,
Andrew
If the struts2 actions were created properly there would be a clean API to the service layer already. Hopefully the Struts2 application is already using Spring DI. Struts2 objects could be reused. But the web layer is relatively thin so it would be best to remove any trace of the struts2 actions to simplify further development, rather than leaving weird artifacts.
There are four main parts that a user of struts is responsible for.
The Action Class
Struts2 specific tags in the view layer
Validation
Interceptors
The action class as already mentioned should be quite thin, it's main purpose is to marshal objects on their way to the view. (To marshal them it will need to set form parameters and validate them). If the objects are acquired from the service layer, then you should be able to mostly cut and paste the logic over into Spring Controllers. If you find logic that should be in the service layer, it should be pushed up.
The tags in the view layer I'm not so sure about. Probably best to replace struts specific tags with jstl tags where possible. Struts2 does not have a huge tag set, and there should be a pretty much one to one mapping between the tags but you'll need to figure out what that mapping is (and which tag lib is best).
Validation - I don't know how Spring MVC does validation.
Interceptors address cross cutting concerns, I don't know how Spring interceptors work. Spring could address the issue of custom interceptors probably with AOP.
All in all, the web tier shouldn't be very invasive... and I'm not sure what you'll gain. Be aware that if your current S2 application is not using Spring DI it is quite easy to add, along with AOP and you can even delegate the creation of actions to Spring. As such I would expect very little return in such a conversion. As an alternative, it might just be easier to start building what you need with Spring MVC, and turn the struts2 actions into web services (json is ridiculously easy). Then dismantle them piece wise when you have the time to implement them in Spring MVC. A conversion means understanding two systems and mapping them, it is messy and error prone... this has the same end effect (the removal of the struts2 framework) but would allow for productivity as well.
Related
I am exploring ASP.Net web Api and I am trying to use to create a web page to basically provide option to edit and display some data from DB(MySQL) with some modifications. I also want to provide a REST Api that would be used by mobile app. Now I can do this with the ApiController(to provide REST api) and then the MVC Controller which renders the model(using View method). This works but there is lot of duplication between the API and the MVC controller. Is there a design pattern or something that avoids the redundancy?
I understand that API controller has to return JSON and the MVC controller has to return the Model for the view.
There are two general paths you can follow to remove duplication.
Use js frameworks and rely on the rest API for all data. Knockout, breeze and countless other frameworks exist to support this, because it is how SPAs are made. You can get lost in all the frameworks, so when you find the ones you like, learn them and run with them. I'm using this structure on my latest web app with knockout and sammy (for routing)
Fat model, skinny controller. How you actually handle this depends on the complexity of your data. MVC can have multiple layers. You could use the API's view as the model in the MVC's controller and view. You could present a DAL that handles queries and reference that from both controllers. Either way duplication is removed.
Is it fair to say that the most important justification to use Spring Webflow over Spring MVC is this:
Using Spring MVC, the different stages of the workflow needs to be in code. i.e. If Stage 1 ends in success, in the Controller we need to forward to the jsp for stage 2 and so on. In SPring MVC, we cannot do it in xml file.
But in Spring webflow we can configure the flow in xml file without touching code.
Is this wrong or over simplification? I looked at http://forum.springsource.org/showthread.php?16393-Difference-between-Spring-MVC-Web-Framework-and-Web-Flow and was trying to make a summary of the explanation.
If your application have complex Flow pages, events which need to be defined as Finite state machin then use Webflow. It would be justified to use webflow for website where you buy Insurence, Flight Tickets.
Otherwise use normal MVC framework like Struts, learning curve for webflow can be bit hard than other MVC frameworks.
I would say below point mentioned in post is fully justified.
The main point: webflow is a powerful controller. That's it. Use it when you need its power. use plain old controllers where you don't.
Taken from http://forum.spring.io/forum/spring-projects/web/web-flow/7159-difference-between-spring-mvc-web-framework-and-web-flow
MVC is an implementation of the Model View Controller design pattern, webflow is an implementation of a "web flow" state machine.
Web flow sits on top of springs MVC and allows you to define complex navigational flows.
Quite simply; if you have lots of independent single pages, which don't do much and don't interact, use plain old MVC. If you have a set of pages that represent a workflow, use webflow to model the workflow. If you have both; mix and match
I am new to java(learning JSF and other JAVA EE components) and have a very basic question.
Why do we need a Servlet when lot of the things can be done with Beans. What is there in servlet which cannot be done from a Bean or how is using Servlet better than Beans in a web based application.
With JSF, you're basically already using a servlet, the FacesServlet which you've most likely already registered in the web.xml yourself in order to get JSF to run. It's exactly that servlet which removes the need to write a bunch of servlets to perform repeated tasks such as gathering the request parameters, converting/validating them, updating javabean properties, invoking actions and navigating to the right view.
In JSF you do not need to create additional servlets to perform those tasks. You just create and declare a managed bean as a controller which in turn holds a simple javabean class as model which get bound to UI components in the view.
But sometimes JSF is overkill or too hard whenever one has never learnt JSF before and just want two, three or four web pages with only a contact form. JSF has a relatively steep learning curve, which requires a solid understanding of HTTP servlets as well. With "plain vanilla" servlets and JSP it's then easier to develop. But whenever the site grows out of its borders and you start copypasting/refactoring the common tasks, you'd be happy if you had chosen a MVC framework beforehand.
Beans are used to represent your data.
Servlets should be used to control your process.
In the MVC(Model, View, Controller) pattern Beans would be your Model which are data-centric and represents your data, act as the domain objects or simple data structures.
Servlets are the Controller that calls the correct model and dispatches them in the right order. They can be used to get the user requests and translate them into the right input for the Models to operate on.
I know the answer is very high level, but try to read-up on MVC pattern, you will get the idea better.
I would like to implement the MVC pattern to an existing Flex project. I want to separate out the controllers and models from the views. They currently all live together in large mxml files.
My question is, should httpservice requests be in the model or the controller? What sort of advantages/disadvantages would there be to either?
I normally try to abstract any service request into a Command call (execute, result, fault) which gets the service it needs to called injected in (which can be a good idea to abstract even more and be a service delegate).
There's a good example of how to use short lives command objects in Parsley's dev manual (one of the more popular frameworks).
I would rather approach the services as something totally different - an MVCS, not just MVC. You should check the Introduction to Flex Application's Architecture I wrote in my blog.
I looked at httpservice, and it seems to me that, while the service itself might reside in a repository or Service Layer (between the controller and the model), using the service involves references to UI elements such as DataGrid. So the implementation of that service probably would occur in the controller, or even in a ViewModel object.
I was reading this blog post on ASP.NET MVC 2's new model validation and found it to be pretty cool. I see the value in keeping things DRY by adding a couple attributes to a class property and then automagically getting client and server side validation (as long as your controller checks for valid models).
That said, imagine an ASP.NET MVC application in a greater context. Perhaps I have an ASP.NET MVC application with this validation and all, but then I want to expose things to new clients, like an iPhone or Android application (not just a mobile browser). I would have to write some web-services or something that use the same underlying repositories/services that my ASP.NET MVC app uses. Could I re-use this validation stuff?
Wouldn't I have to re-write the client-side validation? I don't see a way around this, since I'll be shipping off serialized objects to be de-serialized into non-C# classes from Objective-C or whatever.
Wouldn't I also have to re-write the server-side validation? Is there some way for me to call into the ModelState on an object outside the context of an ASP.NET MVC controller (e.g., as part of the web-services I create to talk to mobile clients).
Assuming you are talking about Data Annotations, they are not part of MVC actually. So you can use them elsewhere as you wish.
There are other work extending them - annotationscontrib is one of them and I guess you can look at how, for example ModelBinder is implemented and write your own service using that.
xVal Project is possibly doing along the same lines as what you are after - converting the validation rules into Javascript. Unfortunately I am not sure how much effort you need to adapt xVal for your project or rewrite it.
As for running the validations on the annotated classes one can use the Validator (thanks womp)