5 ms·

Most criticism of MVC and frameworks can be summarized as: "I don't understand MVC, this framework I'm using doesn't supply me with a one-size-fits-all archite

Most criticism of MVC and frameworks can be summarized as: "I don't understand MVC, this framework I'm using doesn't supply me with a one-size-fits-all architecture for my business logic and I'm incapable of designing my own. So I'll just stuff my spaghetti style code somewhere, and bitch about MVC and/or the framework being insufficient/dead/shit." It's the ultimate expression of a bad craftsman blaming his tools, and it's endemic in web development.

hvidgaard 13y ago
I've lost count of how many times I've had to argue that the View binds (loosely put, for View <-> Model interaction) directly to the Model. The Controller only enters the chain if the operation is more complex, i.e. it is a composite operation. That said - the Controller is the only place that is left if the code isn't interface or datastorage specific, so naturally it's the first place to get bloated. But that's fine, you just have to take care of that when you can, by abstracting common functionality and/or move it out in a library.
gizzlon 13y ago
"this framework I'm using doesn't supply me with a one-size-fits-all architecture for my business logic and I'm incapable of designing my own" Funny, because too me that seems like the whole point of MVC: To have a one-size-fits-all "architecture" to shoe-horn your business logic into. But then again I never really understood the point of MVC. It seems like a somewhat nice fit for GUI applications, but that doesn't mean you should use it for everything. The real takeaway is to decouple and abstract to the point that makes sense. Not too much and not too little.
popee 13y ago
> it's endemic in web development Important word here: 'web'. If you move that word all ror puritanism falls apart. For example imagine multi-protocol MVC. In that sense javascript is really part of view and it can 'pass messages' to model using ajax.

hvidgaard 13y ago

I've lost count of how many times I've had to argue that the View binds (loosely put, for View <-> Model interaction) directly to the Model. The Controller only enters the chain if the operation is more complex, i.e. it is a composite operation. That said - the Controller is the only place that is left if the code isn't interface or datastorage specific, so naturally it's the first place to get bloated. But that's fine, you just have to take care of that when you can, by abstracting common functionality and/or move it out in a library.

gizzlon 13y ago

"this framework I'm using doesn't supply me with a one-size-fits-all architecture for my business logic and I'm incapable of designing my own" Funny, because too me that seems like the whole point of MVC: To have a one-size-fits-all "architecture" to shoe-horn your business logic into. But then again I never really understood the point of MVC. It seems like a somewhat nice fit for GUI applications, but that doesn't mean you should use it for everything. The real takeaway is to decouple and abstract to the point that makes sense. Not too much and not too little.

popee 13y ago

> it's endemic in web development Important word here: 'web'. If you move that word all ror puritanism falls apart. For example imagine multi-protocol MVC. In that sense javascript is really part of view and it can 'pass messages' to model using ajax.