I have a Spring MVC controller that handles about 6 or 7 URLs, each with a POST and GET. Most are related functions (issue refund, change price, etc).
Are there any guidelines or best practices for breaking up a controller by URL or function?
Part of me wants to have a separate controller for each GET/POST pair. If there is any duplicated code, I'd create a utility class.
I am curious to know how others handle it.
I usually break it up by the URLs. But I usually have one GET and then multiple POST requests (1). However, if there are only GET/POST pairs inside some functionality, I put them in a 'parent' controller (2).
(1) For example for the "Promotion" functionality (that has different kinds of promotions handled) I would make PromotionController as the main controller for that functionality and than make controllers for every kind of the promotion.
(2) For example for the "Registration" functionality, which has few steps and in every step just the GET/POST pair, I would put it all in the one controller.
Related
A topic about single action controllers is in the laravel documentation:
https://laravel.com/docs/5.5/controllers#single-action-controllers
My question is, what is the use case where you will use this controllers? How will you structure your controllers if you opt to use single action controllers for all your controllers?
Michale Dyrynda seems to sum up the pupose of Single Action Controllers in his blog: https://dyrynda.com.au/blog/single-action-controllers-in-laravel
Conclusion
Single action controllers are an effective way to wrap up simple functionality into clearly named classes.
They can be used in instances where you're not necessarily following a RESTful approach; be careful not to separate multiple actions for a single entity across multiple controllers.
Where you might have previously used a single controller for multiple static pages, you could consider separate named controllers for each static pages.
You can add other methods to this class, but they should be related to the single action this controller is responsible for.
He also states that, you should only use these when you only need a single action for an entity:
You may consider naming the controller ShowPost as a way of being explicit about the controller's intent but I'd suggest caution with this approach; if you start seeing ShowPost, EditPost, CreatePost, etc controllers creeping into your codebase, I'd reconsider the RESTful approach. More controllers never hurt anybody, but we should be smart about when this is done!
This is an intresting question and my answer is not related to laravel, but to the single vs multiple actions per controller.
I have found when trying to find the use case for a pattern that is new, is to ask the inverse questions, in this case, when is the use case of multiple actions per controller make sense?
The answer usualy comes to:
You have an object that has crud operations (because your using sql)
and its convenient to place all the stuff related to that object in
one spot.
This is akin to the answer of "I have a hammer, so everything is a screw" and IF your domain is as simple as a thin layer over a crud database, then that is the use case for multiple actions per controller.
What I have found is that any amount of complexity blows up the controllers, no matter how good your model is. The reason is CRUD opperations are apart of your model, not your controller.
We usually think that we will map nicely to a CRUD model in our controller, there are many front end frameworks that work amazing at that, untill....
Look at the most common aspect of applications, users. In the setup your going to have index of users, which I don't know who would look at that page besides admins, and they usualy want extra information. so for the index action, you need admin custom authentication.
Then creation, well, it does not make sense to have an user create an user, you need to ensure the user is not authentication.
Now we talk about reading. What data an admin, other users, current user, and anon user can see is massivily differnt, and will slowly build up in complexity.
Then delete, this is normally rare action, and on some models not needed, but you still put it up, because, well you have a hammer.
The update, do you put password updates in here too? what if the user forgot there password? do you put that in here? No, you make a new action called forgot password.
Well now you need update password action. What goes in the update is usually a gigantic mess of hell after a year.
Each pattern has its pros and cons, my general advice is to do multiple actions per controller when your system is trully CRUD OR you will not have to maintain the project for more than a year. If you have any amount of complexity that will have to maintained, avoid the model leaking into the controller and keep them seperate.
I would highly appreciate it if someone can share their thoughts on this. I am new to Spring, but not new to MVC. However, my exposure with MVC has mostly been on the front-end side of things.
Lets say if I have a dynamic site which employs SpringMVC Framework 3.0, and site has 5 links such as:
HOME | FAMILY | COMEDY | HORROR | ACTION
Each of these links would query a database and display information. If I was to be doing this for front-end via a MVC framework, I would have five different controllers, but I came across a question here (Stackoverflow) which talks about having just one controller and then numerous resolvers. I would like to know what is the correct approach?
Here is the link to the mentioned question:
Spring controller setup question?
As Jaanas said, it really depends on how you are retrieving the data for each link and whether the resulting pages are all based on the same data model and templete (JSP) or are completely different to each other.
I tend to use a separate controller for "home" but if those other pages are simply querying a database then, I'd start serving those from a single controller.
Its also a good idea to try and think of your pages in terms of REST principles. Once you start seeing the links in terms of REST URIs, then the decision of whether the various URIs go in the same or separate controllers is obvious. E.g. if the URI for "family" is /movie/genre/family, then it becomes clear that all 4 of those links should go in the GenreController class (or a MovieController class, with a /genre method capturing the category with a #PathVariable annotation).
It depends on how much logic you have behind each link. If you have only one mapping in each controller, you could use single controller.
That said, I still prefer having separate controllers, when doing only small project like yours.
On the other hand, if your project expands, you could end up having absurd amount of controller, that don't do much. In that case you could group your controllers from start, so grouping similar controllers, that have almost equal logical side.
The number of controllers in your application depends on the scope of your project. If you have fixed requirement and the number of operations are limited then you can use single controller which will handle your all request.
But if your requirements are not fixed or going to increment with your application version, you must use separate controller for separate module. So that in future you can easily manage your application code.
For better code maintenance, I will prefer to use separate controller for each module.
I have a question concerning the structure of an MVC application. Suppose we have to realize a web-based application composed by several modules, such as shopping cart, store browser(end-user), store manager(admin) and so on.
It is of course possible to create one controller and use the routing to submit the requests to a specific controller's action method. However this would make the code quite messy and hinder the practice to vertically structure the application, namely to identify and distinguish which views, models and controllers are involved to fulfill a specific requirement (an example is given by Phil Haack).
Another approach is to use one controller for each application section, for instance one controller made available for end-user operations, another for the store administrator, another one for queries made by the shipping department and so on. The drawback to this approach is to have too many controllers that mess up your code, too dedicated for specific tasks and so difficult to reuse.
According to this two extreme situation, what is the best way to organize your controllers and routing policies? Do you use a structured approach or it depends on the type of application you are developing?
Thanks
Francesco
It is of course possible to create one controller and use the routing to submit the requests to a specific controller's action method. [...]
Another approach is to use one controller for each application section, [...]
You're overlooking a third alternative, which is the most common one. In general you should have one controller per resource. A resource is a model that is publicly exposed. In your specific storefront application, the resources would be things like Products, Orders, Customers, etc.
This is typically the proper level of abstraction, because controllers usually don't need to know about models other than the resources they touch. A controller that touches more than one resource should be viewed with some skepticism, since it's violating the single-responsibility principle.
You should try to follow REST as much as possible
Basically - that means controller for each 'collection' (Your entity).
If Your controllers will be RESTful, other parts (routing, views) will fit themselves accordingly.
Simple examples of controllers in a RESTful architecture suggest four actions per controller -- index, create, update, delete -- corresponding with the GET, POST, PUT, and DELETE. But beyond that I still find a dozen little decisions:
Do you have a different controller for resource collections (example.com/things) than you do for an individual resource (example.com/things/123)?
With individual resources, is it preferable to pass the id in as a parameter to the action, or set it as a member variable in the controller class?
How do you go about URI routing? The old tried-and-true example.com/{controller}/{action} approach kind of falls apart.
What about subordinate resources like example.com/user/123/things? Do you have to explicitly define every route for these or is there a way to write a good general rule?
Do you differentiate between API requests and browser requests, or do you channel them through the same controller and/or controller methods?
Obviously, you could go about these things a dozen different ways, but I'd really like to not have to re-invent the wheel if others have hashed through the problem. I'm looking for any advice or maybe better some good tutorials that deal with these (and other related) practical issues in designing a RESTful mvc framework.
My controllers have methods Get(), Put(), Post(), Delete(), etc. I think using the "action terms" confuses the issue.
I always create a different controller for collections and single things. To me they are very different resources and I want the HTTP methods to do different things.
Routing I do differently than most frameworks. I don't match on the entire url, but on a segment by segment basis. It is similar to the way SubResources work in JAX-RS
For services that only have a small number of distinct resources then using regex style url pattern matching is fine. I just found it started to break down once you start dealing with hundreds of resources.
My MVC app tends to have a lot of ajax calls (via JQuery.get()). It's sort of bugging me that my controller is littered with many tiny methods that get called via ajax. It seems to me to be sort of breaking the MVC pattern a bit--the controller is now being more of a data access component then a URI router.
I refactored so that I have my 'true' controller for a page just performing standard routing responses (returing ActionResponse objects). So a call to /home/ will obviously kick up the HomeController class that will respond in the canonical controller fashion by returning a plain-jane View.
I then moved my ajax stuff into a new controller class whose name I'm prefacing with 'Ajax'. So, for example, my page might have three different sections of functionality (say shopping cart or user account). I have an ajax controller for each of these (AjaxCartController, AjaxAccountController). There is really nothing different about moving the ajax call stuff into its own controller class--it's just to keep things cleaner. on client side obviously the JQuery would then use this new controller thusly:
//jquery pseudocode call to specific controller that just handles ajax calls
$.get('AjaxAccount/Details'....
(1) is there a better pattern in MVC for responding to ajax calls?
(2) It seems to me that the MVC model is a bit leaky when it comes to ajax--it's not really 'controlling' stuff. It just happens to be the best and least painful way of handling ajax calls (or am I ignorant)?
In other words, the 'Controller' abstraction doesn't seem to play nice with Ajax (at least from a patterns perspective). Is there something I'm missing?
While you might put Controller on the end of it to make ASP.NET MVC's routing magic work, I tend to do what you've already done--except when I read AjaxCartController I think to myself AjaxCartPresenter (as in the Model-View-Presenter pattern commonly seen in WinForms). That is, this "controller" is not controlling but instead unashamedly tied to the view interface. But, unlike the view, the controller presenter is testable.
When we AJAXify a Web page, we're turning it into something that can react in a fine-grained manner, so fine-grained methods are okay. Fined-grainedness is the point and the whole reason it was invented. We are deliberately walking away from REST for a particular scenario because that particular pattern is not solving the UI requirement at hand, instead choosing an RPC-like model. They are just patterns, one is not going to be better than the other in all situations, even if our technology stack might be pushing us toward one over the other. (Indeed, HTTP itself does better in chunks/pages/entities/representational state transfer documents.)
Mentally, you can treat these pages as if they were forms in a WinForms application; the fact that these methods sit in a "controller" is just an artifact of and concession toward the technology being used. (If it super-duper bothers you, you could roll the AJAX methods into an IHttpHandler and bypass MVC entirely, but why throw away the automatic routing/instantiation/method lookup and make it difficult for yourself? It would be architecturally 'clean' and pure but of dubious benefit.)
... at least, that's how I rationalize it to myself =)
If you have too many fine-grained requests, you might want to have one Controller Action method to service all the calls. You might use a 'switch' in the method to determine the call type and service it accordingly instead of having a zillion tiny methods. You might even use explicit string constants instead of numbers for the switch variable.