Seems like a reasonable way to structure an application. It would be great to see a concrete example or two. The login example that is sketched out gets you partway there.
MVC is dead, it's time to MOVE on
11–20 of 233 posts
Re: MVC is dead, it's time to MOVE on
#12I prefer the term "Services" over "Operations".
Services is where the logic of your application should live, and services should be HTTP (or any protocol) agnostic. They should only speak in models and native types, and should abstract all of your logic away from your controllers and models.
This leaves the controllers as a thin http handling layer that parses inputs and then lets the service handle the work.
The response from the service is then transformed appropriately (JSON, HTML, etc) and sent back to the caller.
Just my $0.02
Re: MVC is dead, it's time to MOVE on
#13This 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 into. Just because there is a bunch of code that ends up in the controller because "you don't know where to put it" doesn't mean there isn't a better place to put it without re-designing the entire application.
Another thing is while I love the data-binding event deal, this really only works for client-side frameworks like Backbone. Server-side kinda goes at the window, but I suppose you could add a framework that piped event signals in the response from changes that occurred in the ORM layer (although this further couples components).
I'm not convinced that separating the data from the methods that operate is a great idea unless you want to go purely functional. Doing this clearly breaks encapsulation, throws any notion of OOP out the window, and still binds the "operations" too closely to the data. Generally speaking, the data is useless without the operations and vice versa.
So the real difference between MOVE and MVC, at least according to this article, is that models are no longer useful on their own, the controllers aka "operations" know everything about how to manipulate models (it shouldn't), and models generate events which are only consumed by views, which makes no sense if you wanted to use the model on its own (but you can't without your operations).
Generally speaking, the model should MODEL something. That includes data and behavior. Without both, you have a database, and a set of operations kinda like a C library but only because OOP hadn't been invented yet.
In my mind this further couples all of the components because it actually increases the reliance on each other for them to be useful.
MVC isn't dead. There is a good chance you are using it wrong. I highly suggest Rails Antipatterns. While it is specific to Rails, it works for MVC in general. http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison...
edit: spelling
Re: MVC is dead, it's time to MOVE on
#14Are there any MOVE frameworks yet? I very much like the idea, but one of my favorite tests for "correctness" in a program is to use it to build something. Although it could be (and probably is) a reflection on my lack of knowledge, I find myself "fighting" with MVC frameworks like backbone whenever I try to use them. I would love to see if MOVE would be any better.
MVC may not be a solid pattern for a client side framework. It makes sense to contain some semblance of state with in the presentation layer on the client side, rather than working with a stateless MVC pattern.
http://www.martinfowler.com/eaaDev/uiArchs.html MVP via M. Fowler seems a little closer to what client side should feel like (imho).
http://en.wikipedia.org/wiki/Model_View_ViewModel MVVM also makes sense for a client side app, which is just an extension of MVP.
IMO MVC on the client side is just a carry over from people who were experienced in writing web apps who wanted something that felt familiar on the client side. It's a leaky abstraction at best.
Re: MVC is dead, it's time to MOVE on
#15Seems like the Operation layer is a combination of controllers and business logic, which feels like a bad idea to me. If the models only wrap knowledge, but don't do any work, then it's the part of the Operation to both decide what to show and also get it in the correct format to show. This seems like it's doing too much and is analogous to the MVC problem of really fat controllers.
Re: MVC is dead, it's time to MOVE on
#16So you renamed "controllers" to "operations".
No. An operation appears to be a one-off "action" rather than a collection of actions (like a controller).
Re: MVC is dead, it's time to MOVE on
#17Can't wait for the first MOVE framework to come out: "Mumia"
Re: MVC is dead, it's time to MOVE on
#18Re: MVC is dead, it's time to MOVE on
#19So you renamed "controllers" to "operations".
It splits controllers into operations and events.
Out of the three terminologies (state, representation, flow), the third one is arguably the most tangled. I find it healthy to refactor it into reusable chunks (operations) and event-driven flow management.
The problem was, in my opinion, that operations should have not been put into controller units. It attracted more copy-paste solutions in my experience.