5 ms·

"You have models, which are nice self-contained bits of state, views which are nice self-contained bits of UI, and controllers which are nice self-contained bit

"You have models, which are nice self-contained bits of state, views which are nice self-contained bits of UI, and controllers which are nice self-contained bits of...What?" Business logic

mgkimsal 13y ago
Amen. Except... the current trend I'm seeing/hearing is "nothing in controllers". There seems to be some hatred of controllers controlling anything.
- neeleshs 13y ago
  The reason is that the code in controllers tend to be view specific in practice, to the extent of projecting view specific models. If you wanted to expose your business logic as APIs, you are better off either writing controllers view agnostic, or pushing down the business logic to something else.
- TylerE 13y ago
  I think there is a certain amount of "those who do, do, those who can't, teach" going around in the framework space. To-Do List apps and Photo Galleries don't have business logic.
  - dustingetz 13y ago
    Todo lists do have business logic, but the logic is so simple that one might not notice when it gets coupled to the views. so you can get away with coupling things like "MV-whatever" or MVVM for apps up to a certain threshold. Facebook is an example of an app well past that threshold, so we should probably listen to them when they talk about their new DOM management library, Facebook React.
- rgbrgb 13y ago
  One of the big ideas for me was that the controller is the least reusable, most application specific piece. With that in mind, keeping the bulk of the business logic and view logic in highly testable and reconfigurable models and views makes a lot of sense. I think of a controller as a mapping between model and view -- it takes internal state and pipes it to some views then takes external stimuli and pipes it to some models.
  - dustingetz 13y ago
    exactly, and the application specific-ness is what makes them hard or poorly understood. General DOM management libraries can't provide a controller. For one thing, it needs to interface with your backend.
tieTYT 13y ago
Wrong. Business logic is part of the model. Source: http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/ref=sr_sp-atf_title_1_1?ie=UTF8&qid=1378943780&sr=8-1&keywords=martin+fowler+business+logic http://www.amazon.com/Patterns-Enterprise-Application-Archit... http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93cont... http://stackoverflow.com/a/4415941/61624 http://stackoverflow.com/a/4415941/61624 http://programmers.stackexchange.com/a/165446/56945 http://programmers.stackexchange.com/a/165446/56945
- ryeguy 13y ago
  Not necessarily, putting business logic in the models as opposed to service classes is a recipe for disaster in any decent sized application. People are realizing this, even in the rails community, and are moving away from it. Putting business logic in the model is not a scalable solution and generally leads to god objects. Unless your definition of model is the business logic area of your application. Saying that business logic goes in the model, in terms of the general rails sense, is the bad route.
  - dreamfactory 13y ago
    I'd say the model is a black box for business data and logic yes. So I'd consider the M and O from the article to be the model - encapsulated data + behaviour. IMO the E part of the article maps to the controller layer (in the web version of MVC). I think there are two areas of confusion on the topic: 1. Web MVC isn't the same as the traditional MVC pattern as seen in apps and described in patterns literature. In the web version all communication between model and view is mediated through the controller layer and there is no direct control between them) - many web developers are only aware of this variant. 2. Rails popularised web MVC and used ActiveRecord which meant that models were essentially table wrappers and this pushed business object logic into the controller. For me the next step after MVC is PAC - http://en.wikipedia.org/wiki/Presentation%E2%80%93abstraction%E2%80%93control http://en.wikipedia.org/wiki/Presentation%E2%80%93abstractio... (which I think is pretty much the same thing as HMVC). Adding that extra dimension of multiple self-contained triads keeps the controller layer from becoming a single unwieldy mess of spaghetti spread across the whole web layer. (Ironically I suppose it does introduce a concept of events binding them which may bring it full circle to some ideas in the article.)
gbog 13y ago
Oh my god no! Business logic is in the model. For example "a new user cannot be created if its email is already used by another user". Would you put that is the controller? Controller is just orchestrating the basket dance of the views and the model. Got this user input, fwd to this model, got this result from the model, wake this view.
- curveship 13y ago
  I think the problem is that "business logic" is too vague a term, spanning what can be called both "rules" and "behavior." What you've cited -- "emails must be unique" -- is a business rule and belongs in the model, since only the model can enforce a data invariant like that. But take something like "new users are sent a welcome email." Would you put that in the model? Personally, I wouldn't (my User model is supposed to know about the mail service? really?). That fits into the class of behavior and belongs in a controller. Put another way, when business rules change, you change your models. When business behavior changes, you change your controllers.
  - gbog 13y ago
    Well, you are right, the model should not send the mail to new users. There should a way for the mail service to poll the model for emails to be sent. So the business rule here is still coded in the model. Say you want to also send the same email to old inactive users, you should just need to change the model, add a new business rule. If you add such rules in the controller, you have to split your rules in two places, which is bad. Ideally, I always thought that business rules should be a kind of "config", or more accurately a set of files written in a mini-domain language, that would be readable by PMs. Then it would be the job of the model to interface this set of rules with the controller. So no, business rules and logic and whatever do not belong to the controller.
  - asdasf 13y ago
    >But take something like "new users are sent a welcome email." Would you put that in the model? Yes, 100% absolutely, no question. >That fits into the class of behavior and belongs in a controller. The controller is just to handle input, it has nothing to do with behavior. This is one of the key misunderstandings that differentiates between MVC and the weird mess rails calls MVC.

"You have models, which are nice self-contained bits of state, views which are nice self-contained bits of UI, and controllers which are nice self-contained bits of...What?" Business logic

mgkimsal 13y ago

Amen. Except... the current trend I'm seeing/hearing is "nothing in controllers". There seems to be some hatred of controllers controlling anything.

neeleshs 13y ago
The reason is that the code in controllers tend to be view specific in practice, to the extent of projecting view specific models. If you wanted to expose your business logic as APIs, you are better off either writing controllers view agnostic, or pushing down the business logic to something else.
TylerE 13y ago
I think there is a certain amount of "those who do, do, those who can't, teach" going around in the framework space. To-Do List apps and Photo Galleries don't have business logic.
- dustingetz 13y ago
  Todo lists do have business logic, but the logic is so simple that one might not notice when it gets coupled to the views. so you can get away with coupling things like "MV-whatever" or MVVM for apps up to a certain threshold. Facebook is an example of an app well past that threshold, so we should probably listen to them when they talk about their new DOM management library, Facebook React.
rgbrgb 13y ago
One of the big ideas for me was that the controller is the least reusable, most application specific piece. With that in mind, keeping the bulk of the business logic and view logic in highly testable and reconfigurable models and views makes a lot of sense. I think of a controller as a mapping between model and view -- it takes internal state and pipes it to some views then takes external stimuli and pipes it to some models.
- dustingetz 13y ago
  exactly, and the application specific-ness is what makes them hard or poorly understood. General DOM management libraries can't provide a controller. For one thing, it needs to interface with your backend.

tieTYT 13y ago

Wrong. Business logic is part of the model. Source: http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/ref=sr_sp-atf_title_1_1?ie=UTF8&qid=1378943780&sr=8-1&keywords=martin+fowler+business+logic http://www.amazon.com/Patterns-Enterprise-Application-Archit... http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93cont... http://stackoverflow.com/a/4415941/61624 http://stackoverflow.com/a/4415941/61624 http://programmers.stackexchange.com/a/165446/56945 http://programmers.stackexchange.com/a/165446/56945

ryeguy 13y ago
Not necessarily, putting business logic in the models as opposed to service classes is a recipe for disaster in any decent sized application. People are realizing this, even in the rails community, and are moving away from it. Putting business logic in the model is not a scalable solution and generally leads to god objects. Unless your definition of model is the business logic area of your application. Saying that business logic goes in the model, in terms of the general rails sense, is the bad route.
- dreamfactory 13y ago
  I'd say the model is a black box for business data and logic yes. So I'd consider the M and O from the article to be the model - encapsulated data + behaviour. IMO the E part of the article maps to the controller layer (in the web version of MVC). I think there are two areas of confusion on the topic: 1. Web MVC isn't the same as the traditional MVC pattern as seen in apps and described in patterns literature. In the web version all communication between model and view is mediated through the controller layer and there is no direct control between them) - many web developers are only aware of this variant. 2. Rails popularised web MVC and used ActiveRecord which meant that models were essentially table wrappers and this pushed business object logic into the controller. For me the next step after MVC is PAC - http://en.wikipedia.org/wiki/Presentation%E2%80%93abstraction%E2%80%93control http://en.wikipedia.org/wiki/Presentation%E2%80%93abstractio... (which I think is pretty much the same thing as HMVC). Adding that extra dimension of multiple self-contained triads keeps the controller layer from becoming a single unwieldy mess of spaghetti spread across the whole web layer. (Ironically I suppose it does introduce a concept of events binding them which may bring it full circle to some ideas in the article.)

gbog 13y ago

Oh my god no! Business logic is in the model. For example "a new user cannot be created if its email is already used by another user". Would you put that is the controller? Controller is just orchestrating the basket dance of the views and the model. Got this user input, fwd to this model, got this result from the model, wake this view.

curveship 13y ago
I think the problem is that "business logic" is too vague a term, spanning what can be called both "rules" and "behavior." What you've cited -- "emails must be unique" -- is a business rule and belongs in the model, since only the model can enforce a data invariant like that. But take something like "new users are sent a welcome email." Would you put that in the model? Personally, I wouldn't (my User model is supposed to know about the mail service? really?). That fits into the class of behavior and belongs in a controller. Put another way, when business rules change, you change your models. When business behavior changes, you change your controllers.
- gbog 13y ago
  Well, you are right, the model should not send the mail to new users. There should a way for the mail service to poll the model for emails to be sent. So the business rule here is still coded in the model. Say you want to also send the same email to old inactive users, you should just need to change the model, add a new business rule. If you add such rules in the controller, you have to split your rules in two places, which is bad. Ideally, I always thought that business rules should be a kind of "config", or more accurately a set of files written in a mini-domain language, that would be readable by PMs. Then it would be the job of the model to interface this set of rules with the controller. So no, business rules and logic and whatever do not belong to the controller.
- asdasf 13y ago
  >But take something like "new users are sent a welcome email." Would you put that in the model? Yes, 100% absolutely, no question. >That fits into the class of behavior and belongs in a controller. The controller is just to handle input, it has nothing to do with behavior. This is one of the key misunderstandings that differentiates between MVC and the weird mess rails calls MVC.