Isn't this what CQRS attempts to do? [CQRS]: http://martinfowler.com/bliki/CQRS.html
Sort of but nt quite, it feels much more like data-context-interactions. Really this doesnt kill MVC at all but extends and enhances it.
MVC is dead, it's time to MOVE on
41–50 of 233 posts
Re: MVC is dead, it's time to MOVE on
#42Arguably Cocoa and Cocoa Touch already have this with the responder chain and notifications.
Re: MVC is dead, it's time to MOVE on
#43You know it's nice reading a criticism of something that has an alternative solution offered rather than just going "hey MVC is terrible and you're an idiot for using it". I do however think there's still great benefits to MVC, if you're shovelling code into controllers and can't make it work like it should then MVC is not the right design pattern for the project. Like every other pattern it'll only work when it work…
MVC is terrible for web apps (in the original local GUI domain it's fine for some things), you aren't an idiot for using it because you're probably not actually using it but rather only something loosely inspired by it, and the solution is simply DRY. MVC at its best is simply one manifestation of DRY, but there's no real reason to get too stuck on it when with practice DRY is something you should just always be doing. If MVC falls out of that, great, but if not, so what?
(The original MVC is actually useless for web apps because there is no client-server connection in it, and that profoundly changes everything. There's no point in trying to bash a GUI top-level design into a new client-server world, especially when DRY is just sitting there, waiting for you to use it.)
MVC, MOVE, all the variants just obscure your vision from the underlying and far more important principle.
Re: MVC is dead, it's time to MOVE on
#44Very spot on explanation of what is circulating in my head for months now. This seems to relate to the Data-Context-Interaction movement and what Bob Martin calls Entity-Boundary-Interactor pattern in his latest talks.
Re: MVC is dead, it's time to MOVE on
#45For the curious, read the original papers from R.Trygve : http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
Re: MVC is dead, it's time to MOVE on
#46I'm willing to try it out.
I usually get around the cited issues through dependency injection into the model. That is, instead of placing large amounts of logic in the controller, I let the model hold the logic.
In a naive implementation, this may couple the model to things it shouldn't be coupled to. So, to avoid the model coupling to infrastructure resources (say, storage), I let the controller inject those objects into the model, as needed.
But, I realize that that's an architect-y, OO kind of way to do it that requires some background knowledge which can may obfuscate the code. So, I'm all about making things easier for everyone.
As others have mentioned, it'd be useful to have a more sophisticated example.
Re: MVC is dead, it's time to MOVE on
#47Operations are just a temporary stop on the road to functional programming.
Re: MVC is dead, it's time to MOVE on
#48Does anyone else not really get "MVC"? It seems like every person has their own idea of what it is and no two frameworks can agree on what the necessary parts are. I get the feeling MVC is mostly a bunch of handwaving about separation of concerns, motherhood, and apple pie.
MVC is just a design pattern, a way to organize code, it's not a religion.
I wouldn't like it to be a religion! I'd just like some precision. Design patterns point to a large region of possible configurations, so to say something is "MVC" isn't saying very much.
Re: MVC is dead, it's time to MOVE on
#49This is certainly interesting. I like the event based model. Here are my thoughts: If your controllers are getting fat and spaghetti like, I wouldn't blame MVC. There are many patterns one can use that are compatible with MVC without going to a completely different architecture. For instance, if you need to encapsulate multi-model interaction you can create a presenter abstraction that the controller simply calls int…
Sorry, but data-bound events are not useless in server context. It might be exactly what we need when fat controllers go out of control. Perhaps you meant they are too much of a complication if taken too far to work across all concurrent requests?
Binding data and behavior together breaks the rule of single responsibility, which I believe is far worse than designing separate roles in sepearate components that work together. Models should model the data structure only, if you need a presentation abstraction anyway for multi-model operations. Why not go the extra mile and use this abstraction level for all operations?
It is a false dichotomy that you go either full-OOP or purely functionaly. Models wrap knowledge as the article suggests, That means that, in addition to getters and setters, they might contain functions that let you check "is this the user's password?". I envision these methods to work on a single attribute, whereas multi-attribute and multi-model business logic belongs to operations.
MVC isn't dead, but it was a local maximum OOP gave us. Event-driven development seems to raise and work well with objects and datasets.
Re: MVC is dead, it's time to MOVE on
#50Does anyone else not really get "MVC"? It seems like every person has their own idea of what it is and no two frameworks can agree on what the necessary parts are. I get the feeling MVC is mostly a bunch of handwaving about separation of concerns, motherhood, and apple pie.
For a succinct description that also explains the origins of some of the discrepancies: