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.
Related
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.
In one of my views, I have a ViewModel which I populate from two tables, and then bind a List<ViewModel> to an editable GridView (ASP.NET Web Forms).
Now I need to send that edited List<ViewModel> back to the Services layer to update it in the database.
My question is - is it Okay to send the ViewModel back to Services, or should it stay in the Presentation? If not - should I better use a DTO? Many thanks.
Nice question !
After several (hard) debates with my teammates + my experience with MVC applications, I would not recommend to pass viewmodel to your service / domain layer.
ViewModel belongs to presentation, no matter what.
Because viewModel can be a combination of different models (e.g : 1 viewModel built from 10 models), your service layer should only work with your domain entities.
Otherwise, your service layer will end up to be unusable because constrained by your viewModels which are specifics for one view.
Nice tools like https://github.com/AutoMapper/AutoMapper were made to make the mapping job.
I would not do it. My rule is: supply service methods with everything they need to do their job and nothing more.
Why?
Because it reduces coupling. More often than not service methods are addressed from several sources (consumers). It is much easier for a consumer to fulfil a simple method signature than having to build a relatively complex object like a view model that it otherwise may have nothing to do with. It may even need a reference to an assembly it wouldn't need otherwise.
It greatly reduces maintenance effort. I think an average developer spends more than 50% of his time inspecting and tracking existing code (maybe even much more). Now everybody knows that looking for something that is not there takes disproportionally much time: you must have been everywhere to be sure. If a method receives arguments (or object with properties) that are not used directly or further down the call stack you or others will walk this long road time and again.
So if there is anything in the view model that does not play a part in the service method, don't use it to call the method.
Yes. I am pretty sure it is ok.
Try to use MS Entity Framework and it will help you allots.
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.
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.