I am afraid that I might be getting lazy.
I am developing a ruby on rails application involving about 8 models relating to two types of users: physicians and patients. Most of the logic is inside the models allowing my controller actions to be very short and concise. Plus, it makes the testing fairly straightforward.
I currently envision at least two controllers and the tests that I am writing lead me to believe that most of my user-facing features can be handled by these two controllers. Sure, I can break this into more sensible compartments-like tests for a patients-controller, physicians-controller, patient-medications controller, patient-lab-results-controller and so on. But it seems to me that the only advantage here is more discreet organization.
On to the question, asides from compartmentalization, what are the reasons NOT to use as few controllers as possible, pack them with lots of actions [disadvantage], but keep the actions skinny [advantage]? Or...to take it to an extreme: Why not with MVC, have a bunch of fat models, and one skinny [albeit long] controller rather than a patient controller/model/views+tests for EACH, physician controller/model/views+tests for EACH, etc?
There's organization, as making everything inside a single controller is possible, it's going to be harder to understand and change. Instead of being able to open a file in your editor and finding the action you're looking for right away, you would be scrolling down the file to find what you're looking for.
This also leads to the God object pattern where everything happens inside a single object that's responsible for everything and everyone working at the project will be changing this same object, leading to an eternal merge hell.
And, on Rails itself, there's the RESTful-ness of the framework. Rails embraces the idea of being RESTful and one of the pillars of this idea are the resources and they can only be easily organized in separate controllers. If you try to place two different resources at the same controller you'll probably end up with crazy routes or crazy controller logic to find out which model is being represented.
If you think your controllers have a lot of repeated code, you can DRY them out using some metaprogramming magic or conventions, but it's really better to have them separated, not only for organization but also to simplify your own future maintenance.
If there's a lot of common controller logic, you might consider abstracting it out into a plugin or module that you can mix in when needed. Or the controllers could inherit from a common base controller (much as all controllers inherit by default from ApplicationController, rather than ActionController::Base).
I would advise against having one gigantic controller; a controller should manage the set of actions which pertain to a single type of resource (or the closest analog possible). This idea is even stronger if you are trying to create a RESTful design, in which each controller typically has nothing other than the basic seven actions (index, show, new, create, edit, update, destroy).
So if you want to have URLs like /patients/52394802/lab_results, I think it makes complete sense to have a LabResultsController. If these controllers are lightweight, awesome. I'm of the opinion that their existence is still justified. This shouldn't stop you from trying to make your code DRY; rather, I would simply try to abstract away the common functionality differently.
That's an impossible question to answer. Controllers are about routes and user interactions and views not business logic. Have as many controllers and actions that it makes sense to have for your links and views!
If your business logic is all in your models then it's simple enough. The main difficulty with logic in controllers is that you can't re-use the logic.
Nothing much more to say really. It's up to you to do what makes sense in your app. e.g. have a search controller to search for stuff rather than adding a search action to your existing controllers is not really about anything more than separation and clarity
Related
What is the Rails Presenters folder for?
What goes in this folder?
Why is this folder needed?
presenters is a design pattern commonly reffered to as Model View Presenter(MVP)
This is a derivation of the Model View Controller pattern and is used for creating user interfaces.
It's useful for the Separation of Concerns for making code more DRY.
Here's how Wikipedia describes it
model - interface defining the data to be displayed or otherwise acted upon in the user interface.
presenter - acts upon the model and the view. It retrieves data from repositories (the model), and formats it for display in the view.
view - a passive interface that displays data (the model) and routes user commands (events) to the presenter to act upon that data.
https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter
Presenters in Ruby on Rails
Presenters are simple classes that sit between the model and the view and provide a nice, DRY object oriented way of working with complex display logic.
In Rails, the convention is for them to be located in the app/presenters folder
Here is a userful article that explains the pattern and its use in Ruby on Rails.
https://kpumuk.info/ruby-on-rails/simplifying-your-ruby-on-rails-code/
The Presenters folder is where your Presenter code would go. I know, obvious, I'll explain.
The way I think of Presenters and Decorators is as an abstraction of a Model in order to massage the data attributes before they are given to view.
If you are familiar with helpers, well, Presenters are kind of like helpers in the sense that they are getting some data ready for the view, except helpers usually serve as utility methods for said views, while presenters are more about presenting the actual attributes.
This link explains the difference very well: https://awead.github.io/2016/03/08/presenters/
hope that helps.
Presenters de-clutter your views
When people mention presenters in a rails context (as opposed to discussions of Model-View-Presenter, MVC, MVVM discussions etc) they are referring to a situation where things look really complex in your views: there are plenty of if statements everywhere, and it's difficult to read through it all.
Or to adopt an everyday analogy: imagine you have a really messy house, with stuff piled up everywhere - so that it's difficult to walk through. You can think of a presenter as a large garage where you can neatly organise everything. This makes it much easier to walk through your house, and you still have all the utensils that you need.
Getting back to the rails context: Presenters allow you to remove all that complex logic somewhere else: into the Presenter's folder, so that when you read your views, it will be a lot easier to understand from a higher level. The clutter isn't there, the complexity isn't there: that has been transferred somewhere else. If you want more detail, you will have to go to the relevant folder. The logic need not be contained in a folder called "Presenters" but it can be put there by convention.
I'm just learning the basics of ASP.NET MVC and am wondering what the benefit is in breaking up website logic amongst multiple controllers versus just having a single Controller class that runs the whole website, besides simply organizing code better. (In my opinion, just the latter benefit should not be enough to affect the end user via the url due to separation of concerns: the implementation details of the site should not be being reflected in the urls the site uses, no?)
Some examples on Controllers I've been reading show different controllers for things like "Product" or "User" or "Post". These clearly correspond to classes of objects followed by actions that can be taken on those (looking at the url right now I see stackoverflow.com/questions/ask).
Is there an advantage of splitting up the website into separate controller classes like QuestionsController versus just having a single default controller and handling these actions within it, for example stackoverflow.com/ask-question (besides it looking slightly uglier).
I ask because I'm not particularly interested in making my website RESTful (I looked into it a bit but deemed it too limiting) and instead favour query string parameters to pass information about a request. Therefore, the concept of splitting a url up into controller and action doesn't make sense to me, since the action and class information will be represented in the query string.
Finally, I much prefer the simpler look of urls like www.mysite.com/about versus www.mysite.com/home/about (what does that even mean?), again leading me to wonder what the point of multiple controllers really is.
You can achieve practically any url scheme you desire with ASP.Net MVC Routing. What controllers you have and where your actions live has nothing to do with your urls. Only routing defines your url's. Therefore, there is no reason whatsoever to sacrifice code clarity and organization for the sake of a particular url scheme.
Furthermore, in most ASP.Net MVC applications I've seen, the controllers are already unwieldy, and combining them all into a single controller would increase the disorganization exponentially.
Even small sites have a handful or two of controllers. Significant sites have dozens, very large sites could have hundreds. Do you really think it is in any way at all feasible to combine dozens of controllers into a single one?
The beauty of ASP.NET MVC comes from the fact that it makes separation of concerns so simple. Unlike ASP.NET Webforms where each page is essentially the View and the Controller, in ASP.NET MVC you can abstract your model logic into separate concerns or 'feature groups'. It makes sense to have a ProductsController that handles everything to do with Products because then you can isolate each set of related functionality in your application into uniform groups that are independently testable and maintainable.
Having a DoEverythingController fundamentally defeats the reasoning behind MVC because it clumps all of the model logic together into one giant spaghetti bowl of code, as opposed to keeping it neat and organized. Furthermore, having a Controller that does everything is not especially object-oriented and resembles a more procedural approach to development like many (older) PHP websites which have some central "functions.php" or similar that does everything. It's messy and disorganized.
In regards to your final point, the routing engine in MVC allows you to construct your routes to given controller actions however you want. The About() action of ControllerX and the Contact() action of ControllerY can both have root URLs like /about and /contact so long as you define the routes accordingly.
Edit (too long for comment)
Generally speaking, the controller classes will be pretty thin as far as code and logic is concerned. Well designed controllers will often hand off more complex operations like retrieving data from the data store to some kind of service so that the surface area for failure remains small. Despite the 'thinness' of most controllers, the larger your site is, the more operations will need to occur and the bulkier your universal controller is going to become. Even in non-MVC scenarios, huge code files suck to maintain and update (like "functions.php" above, for example).
If the site you're developing with MVC is small and limited to only a few more-or-less static pages, then using a single controller for all of them might be a reasonable approach, but if you are constructing a scalable application that will change over time it would be truly defeatist to forgo the use of multiple controllers.
Is like to have all files in the same directory or keep files separated in different folders.
Keeping the application organized in separate controller help in many cases:
1) memory performances
Different from Java Servlet where the controller is shared betwen many request, in asp net mvc the controller is created for each request.
Each time the user make a request, the application need to create the controller.
Think at performances comparison betwen create in memory an instance of a fatcontroller of 100k VS one instance of a light controller of 1k.
2) OO benefit
Controllers are classes. Each time you create a new controller you extend the base controller.
In a complex application you can create yours own controrres (can be more than one) and extend the more appropriated.
For example you can create a controller for "products" and extend from it to create a controller for "vegetables products" and so on..
3) Security.
Suppose that in your application you have a page that execute the CRUD actions on a given item of your db:
- display
- edit
- update
- delete
You want to make this page reserved for registered user only.
If you put all this method in one separate controller you can put the annotation [Authorize] on the controller and by default all the methods inside the controller will be protected.
If you put all the application in one fat controller you have to be careful to place the [Authorize] on each method (what happe if you forgive to put the annotation on the delete method?)
[Authorize]
public class ProductController
public ActionResult Index(String id) {
...
}
public ActionResult Update(String id) {
...
}
public ActionResult Delete(String id) {
...
}
4) Security again.
Suppose you write a classic CRUD (Create Read Update Delete).
Now you want to delete the whole CRUD.
If you keep code separate in different controller you simply delete the controller that belog the CRUD.
If you keep all together in a fatcontroller you have to search for the methods that belog to the CRUD in the whole code.
Again: what hapen if you forget to delete the Delete method?
5) practicality
If you put all together you will have methods like this:
product_edit
product_delete
product_rate
product_create
category_edit
category_delete
category_create
If you organize code in separate controller you will have
product
edit
delte
create
rate
category
edit
delete
create
This is good for many reason: want to modify product in item? simply refactor and rename the productController in itemController.
chaiguy
i think this topic has the potential to illustrate (from the answers) the true benefits of using the controllers to do their own 'lightweight' tasks. one of the many benefits that immediately spring to mind is the fact that each controller can have pretty much the 'same' named actions irrespective of the task at hand (create, edit, delete, list etc).
couple this with a good repository pattern for the data access and some nifty T4 templates and you more or less get an easily understood 'plumbing' job created for free.
this is what makes mvc a pure joy for me - the discreet segmentation of related operations into a unified structure. as previously mentioned, what could become unweildy and cumbersome is instead rendered (no pun intended!!) familiar and focussed.
I guess if you like spaghetti, you would only have one controller.
Complexity, complexity, complexity, that is the question. Software is all about breaking a problem down into manageable units.
Hence multiple controllers.
I'm working on my first real ASP.NET MVC project and I've noticed that the controller I've been working in is getting rather large. This seemingly goes against the best practice of keeping your controllers thin.
I've done a good job keeping the business logic out of the controllers. I use a separate layer for that. Each action primarily calls a method in the business layer and coordinates the end result based on whether or not the modelstate is valid.
That said, the controller has a large number of action methods. Intuitively, I would like to break the controller down into sub-controllers but I don't see an easy way to do that. I could simply break the controller down into separate controllers but the I loose the hierarchy and it feels a bit dirty.
Is it necessary to refactor a controller with a large number of thin actions? If so, what is the best way to do this?
First, when you hear that it's good to keep controller code to a minimum, this mainly refers to keeping each action method as thin as possible (put logic instead into business classes, not into Views and ViewModels.) It seems you're doing this, which is great.
As for having "too many" action methods, this is a judgment call. It could actually be a sign of good organization, that you're having each action focus on one thing. Also, maybe you're using actions specifically for use with RenderAction? And, it could just be the nature of your solution that there are many things to do relating to your Controller's theme.
So, my guess is that you're probably fine. However, to make sure, on note paper break out the controller into 2 or 3 controllers, and sketch out how your stories would work moving from action to action. And if you find that your workflow works with more controllers, you should break it out. Especially if you're going to be adding to this functionality later. The sooner your break it out the better.
Good question.
I believe a "thin" controller may still need to be "wide" or "tall" depending on how you want to stretch the analogy. If there is no clean way to break up a controller that needs to do a lot of things, I don't think that's a problem as long as each Action is focused exclusively on preparing Views/ViewModels and is of limited code size.
Another structural option you have is introducing partial classes for logical groupings of actions. And using something like vscommands to group the files together.
I doubt anybody can come up with a magic number of actions that tells you when it's a good idea to break stuff up and introduce new controllers, it really depends on your domain.
Another solution can be to separate the controllers based on the business concepts of the actions that are included in them, but the route of each action is in accordance with the REST rules.
However, I think it is better to use this solution only in cases where there is a fat controller, otherwise, it is better to categorize actions based on their output resources.
I need to have two separate pages on the site I'm planning to build that are very similar that I don't need to introduce new DB tables or models. I would also like to stay RESTful.
If I'm to use the same controller/model I will need to have new methods other than standard index, new, edit...etc which makes it non-restful or I will have to have a variable on page that identifies it and then inside each method I will render different view accordingly.
Another idea I got was to have separate controller and model but use the same DB tables and enforce the model to use the table although it doesn't match the convention.
I'm guessing there might be cleaner way to do this. Do you know any? if not which way do you suggest?
Thanks,
Tam
I'm not afraid of the restafarian police! Sometimes your controllers need more than the 7 actions (where's the get to confirm a delete, eh?), sometimes they will need less. That's just the way it is when you start to create real world software.
If the actions you're adding are not coherent with the actions that exist (for example off by just a little bit but still off in most actions), then we're talking about a new controller IMO - otherwise adding a few actions where you need to is ok in my book.
I always try to make my applications as RESTful as possible but I've recently begun working on a complex project that requires multiple additional methods in my controller.
I normally achieve this by adding another :collection to the route but it seems like a workaround and in on scenario I have 5.
Are there any best practices for handling the extra methods in a controller? They are generally simple forms that updates a model.
The other solution, which is what I do, is every time you find yourself creating an action that doesn't fit into the RESTful actions, eg Search, so you might find yourself making a search action on an Article controller, what you could do instead of creating this action is create a Search controller instead, and use RESTful actions inside of that instead. There is no rule saying you need to use all the actions, you might only need one or two, but it keeps your API RESTful and your code organised.
This is not a hard and fast rule, but I have certainly found it helpful when I try to decide where to put stuff.
I think there's a bit of confusion in the Rails community about how and where to use the word "RESTful". Strictly speaking, the only thing that can be RESTful is your web API (as railsninja already mentioned). That the code of an application that conforms to the REST conventions (the application with REST API) can usually be organized into a set of controllers (that match the resources) and methods in these controllers (that match the four verbs of the HTTP protocol) is nothing but a hint of how to keep your application clean and organized.
If we want to talk about a RESTful Rails application, we can't just talk about RESTful controllers - there's nothing RESTful about just controllers themselves. It's possible to have a complex web application with only one controller (and myriad of methods) that represents many resources and is perfectly RESTful.
That said, it's pretty OK to add more methods to your controller. Sometimes, it's good to extract some of these extra methods and create a completely new controller - make this any time you feel good about it (rule of a thumb: create new controller anytime you are able to identify it with some self-sufficient resource, ie. a resource which could exist just by itself). Sometimes though, it'd be silly to extract some resource to a different controller. Say you have a resource which has a status attribute. It makes sense to perceive this status attribute as a resource by itself and perform at least one action on it (update), but it won't make any good to extract it to a different controller.
There is a Railscast about this topic, adding custom actions to an otherwise RESTful controller.
Edit: I see that you've mentioned the method in the Railscast as a workaround already. :-) I believe the only other "pure" way to handle it would be to add additional controllers as required to support the actions you want.
"I normally achieve this by adding another :collection to the route but it seems like a workaround and in on scenario I have 5. "
This sounds perfectly fine to me. REST is not about the crud operations and your concern seems to stem from the fact that you are doing more than the basic crud operations but there's nothing wrong with that.