Which on would be better in performance among Servlets2.5 and Struts2.
Struts2 uses Servlets underneath.
Theoretically Servlets will be faster than Struts2, however practically you may notice almost zero difference since the bottleneck in your app is least likely to be in your web-app framework.
Struts essentially means there is a default request handler, which
does some pre-processing for you and then calls the individual
controllers....
controllers then call the layer of models to setup the model and then
in a declarative fashion (views are configurable via the
struts-config) forward the request along with the value object
representing the model to the views for rendering.....
this is pretty straight forward - however if you need to make full use
of struts - like the forms,validation,error handling and resource
bundles etc.... at the minimum, you should be able to reuse the model
layer in its entirety without having to write one additional line of
code - IFF - you had designed it correctly in the first place...
with more details about your application - you'll find more help...
Struts2 is better than Servlets. As Struts2.0 has filter has a front end controller while struts1.2 uses Servlets underneath.
Struts2 has interceptor as a class which has inbuild validation. Struts2 has also its own library to create GUI. Struts2 also support OGNL language which is useful to prevent java code in JSP file. and Ultimately, its MVC architecture.
Related
As mentioned in another answer, our use case for Webflow is a bit unusual. Instead of a traditional MVC approach driving UI, with a little effort we exposed SWF as a RESTful HATEOAS API (with some caveats). Our Views are Collection+JSON format with links modelling SWF transitions.
The problem is that SWF tightly binds to the MVC pattern of returning ModelandView, with the View states resolving a view and calling render(). As such till now our choices have largely been to expose the API via a JSP (yuck). We're looking to use Spring Boot (no JSP) and moreover use RestController and Spring Hateoas where instead we want to return ResponseBody<> or ResponseEntity<T> from a controller method, with that being an object formed from the View(state) - i.e. get the Model but no view and generate C-J or HAL+Forms or similar from it with transitions as Links.
We use XML flow definitions (essential to the solution) so I figure either I'd have to
Define a new Flow xsd with custom attributes and monkey with the ModelBuilder code and View implementation. Seems a lot of hackery.
Somehow define a do-nothing MVC view and defer to the customer controller for the HttpResponse when entering View, but how?
Write a complete custom FlowHandlerAdapter (this might help alter the POST-redirect-GET behaviour but won't tackle the ModelandView bit)
"Insert some more elegant answer here"
What is the best route to pursue?
Before this whole thing is considered lunacy, think what SWF brings to proper REST API exposure of business logic - not just another tedious boilerplate example of a CRUD repository API, but loosely coupled declarative workflow. I looked at Spring State Machine also but frankly it seems miles behind SWF on key aspects and doesn't help with state exposure as REST.
Symfony 3 - Should I create two different controllers for REST and normal HTML?
I already have a web application where I am using Symfony controller and twig html templates. So I already have the business logic written to fetch the content. Now I want to expose REST API to share this content with third party. Should I write a separate controller using fosrestbundle ? Or can I use the same controller for both json and HTML? If yes, how?
This might be a highly subjective question and each programmer will have another opinion to this.
I'll try to give you an answer ...
Is the REST Data requested by the page which gets already handled by the controller it might be a better choice to add just a simple json returning function for simplicity.
Are the requirements bigger and for example a third party application may have access to this, you should go with a dedicated REST API, since there may be complete different requirements for security, response times and so on.
At the one hand, a simple Controller can't give you that features and on the other hand it's much cleaner to follow the single responsibility principle with an extra API.
But consider also creating an extra API takes also more time.
So now you should decide yourself for now and for future whether you need an dedicated API or not. The need of third party access sounds to me to go for an extra API.
I've spent a lot of time working in Django, and have grokked the framework well enough that I have started replacing the original components (view engine, etc.) with my own custom components and the sky hasn't fallen down.
I've been looking at ASP.NET MVC, and been quite interested (I really like C#/F#) but so far have learned... just about nothing. I've been digging through http://www.asp.net/mvc/mvc4 without much success. I suppose my main questions would be:
What are the main moving parts in a typical workflow? Let's say a request comes in. Who takes it, does stuff, and passes it on to who else? In Django, for example, a request goes through the URL Mapper, Middleware, goes to a controller, which may dig through some models (via explicit function calls) and get some data, pass it into a template (also via an explicit function call) to be rendered and pass it back.
What kind of client-server coupling is there? For example, in many frameworks there is a explicit coupling of each HTML-form with a serverside-validator, with a model, with a database table, such that client side validation code is automatically generated. Another example is Quora's Livenode, which explicitly links client-side HTML components with their dependencies in the model, allowing changes in the database to propagate and automagically update client-side code.
I think there is no better answer to your first question than ASP.NET MVC Pipeline :
http://www.simple-talk.com/content/file.ashx?file=6068
explained in more detail here :
http://www.simple-talk.com/dotnet/.net-framework/an-introduction-to-asp.net-mvc-extensibility/
To your second question : answer is none. ASP.NET application dont even have to render HTML output, you can write your own viewengine to give any representation of the data, not consumed by browser, but any http (REST) capable device. The only things you can consider as coupling "conventions" (for model binding for example), but they can be replaced and extended in any way you like.
What kind of client-server coupling is there?
As rouen said, none.
I am not familiar with Django, but unlike other MVC frameworks (including Rails) ASP.NET MVC is very skinny in that it only implements Views and Controllers of the traditional MVC pattern. You are pretty much on your own for the model part. That means there is no built-in support for database creation, ORM, et cetera.
ASP.NET MVC does implement a bunch of plumbing to route requests to the appropriate controllers and even some binding of parameters (e.g. query string parameters, form values) when instantiating controllers but this binding is not to a full blown model. The binding in this context is usually either single values or "viewModels"
ASP.NET MVC also implements the plumbing to select the right view to render.
I am trying to understand HMVC and how or if I should consider it in my current MVC app.
Regarding this quote from [this][1] question about MVC architecture,
Sometimes the Hierarchical-Model-View-Controller (HMVC) pattern (aka
Presentation-Abstraction-Control) is a good choice for dealing with
more complex interface and application demands.
"However, the traditional MVC scope falls short when it comes to the
control of GUI elements (widgets). MVC does not handle the
complexities of data management, event management, and application
flows. As an adaptation of the MVC triad, the HMVC --
Hierarchical-Model-View-Controller -- paradigm seeks to redress some
of the above-mentioned issues."
Jason Cai, Ranjit Kapila, and Gaurav Pal (July 2000). "HMVC: The
layered pattern for developing strong client tiers". JavaWorld
Magazine.
[1]:
https://stackoverflow.com/questions/113602/when-to-use-mvc-architecture
I have been trying to understand PAC/HMVC, and the above text struck a chord. The triad abstraction of HMVC can be applied to "widgets" on a page, or how in using the ASP.Net view engine (vs the Razor view engine), would translate to "controls" on the page.
Would that be an accurate application of the HMVC pattern?
If so, I'm not sure exactly how that would be implemented. I do see the advantages of this, in that if the main page loads fine, and some of the user controls/widgets error-out, the page still loads.
So the main page controller would make the call to its widgets controllers? From the main view, I am guessing that model inheritance would come into play, just as you would consume the model's objects in the view of a simple MVC page.
What would that look like in code - calling the model data from say two or three triads down the chain from a top-level view?
Firstly, you raise some interesting points. Secondly, I am making the assumption you are familiar with the ASP.NET MVC Framework.
Just thinking out loud here, there is a HtmlHelper called Partial(), which takes a controller and action and returns the result. So, if you write an Action that returns a PartialView (which could be used a widgets - you can have multiple per page), could this be a plausible implementation of the architecture above?
Thanks,
Matt
After reading different resources of HMVC, I believe ASP.NET MVC does have HMVC since v2.0 in the form of Areas.
Couple that with T4MVC and calling Action.PartialX() methods and you've got yourself the next buzz-word HMVC.
i've build an web application, i have servlet as controler and java classes as the request handdler
so if the servlet receive an request from a client, it will call method from the request handler to process the request, and then the request handler will have to call an ejb to do the business logic, and when the ejb has done it process, the request handler will give the client an response(JSP Page)
so the question is, how to draw the UML based the stucture i've describe above? how to describe relationship between an component(servlet and ejb) with the pojo(requesthandler)?thx for help
is it right to draw like this?
http://i56.tinypic.com/2lmx6c5.jpg
thx
[per question in comment on how to draw class diagram]
Class diagrams are probably most often used for showing relationships in a problem domain. The relationships capture rules from the domain (e.g. "Each order consists of one or more orderlines" / "each orderline forms part of exactly one order").
In your case the classes span the layers of the architecture. Therefore the relationships capture architectural rules rather than domain rules. I don't tend to use class diagrams for that purpose, but the principle is the same. For each pair of classes you need to ask:
How would you describe the relationship among the classes?
What's the cardinality?
For example, take servlet & client. How would you describe the relationship? Probably something like:
description: client calls servlet / servlet is called by client
cardinality: for each given client instance, how many servlets can it talk to? Probably one or more. Similarly, how many clients can a single servlet instance receive requests from? Again probably one or more (will depend on your design)
Assuming above are correct for your design you'd have something like the following (apologies for the formatting, yuml.me doesn't seem to place text cleanly):
Same approach applies for remaining classes. First ask how you'd describe the relationship as a sentence, then figure out the cardinality. For example, take the servlet-request handler: how would you describe that? I'm not very familiar with java EE patterns, but would guess the servlet delegates to the request handler. So relationship phrase would be something like "servlet delegates request to request handler". And so on to ejb class, etc.
hth.