5 ms·

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 realizi

by 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.)
tieTYT 13y ago
I'm not saying put it in models I'm saying it's part of the Model of MVC. If you've got a class called FooBarService that takes a model and executes business logic on it, that FooBarService can still be part of the Model of MVC. If, on the other hand, FooBarService has a handler for a MouseEvent - something that should be done in the Controller - and business logic in it too, now you're violating MVC because your Model and Controller aren't separated. BTW, IMO to name something FooBarService or BazQuxService is a code smell. "Service" carries no significance. Same goes for "Manager" or "Logic" or whatever generic thing you end up using. Any code could be in there. I have to look inside it to see. It also gives you an excuse to make those file huge because anything could be in there. It's a violation of the Single Responsibility Principle. Hah, yes, I'm a Java programmer.
asdasf 13y ago
>Unless your definition of model is the business logic area of your application. Yes, that is the definition of the model in MVC.

by ryeguy 13y ago

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.)

tieTYT 13y ago

I'm not saying put it in models I'm saying it's part of the Model of MVC. If you've got a class called FooBarService that takes a model and executes business logic on it, that FooBarService can still be part of the Model of MVC. If, on the other hand, FooBarService has a handler for a MouseEvent - something that should be done in the Controller - and business logic in it too, now you're violating MVC because your Model and Controller aren't separated. BTW, IMO to name something FooBarService or BazQuxService is a code smell. "Service" carries no significance. Same goes for "Manager" or "Logic" or whatever generic thing you end up using. Any code could be in there. I have to look inside it to see. It also gives you an excuse to make those file huge because anything could be in there. It's a violation of the Single Responsibility Principle. Hah, yes, I'm a Java programmer.

asdasf 13y ago

>Unless your definition of model is the business logic area of your application. Yes, that is the definition of the model in MVC.