I've replaced MVC with VAM -- View->API->Model. I believe it's best to always code the "operations" layer as an API layer. The API always acts on models. Very similar to operations in MOVE, but it clarifies the goals of the layer.
MVC is dead, it's time to MOVE on
91–100 of 233 posts
Re: MVC is dead, it's time to MOVE on
#92The best practices I've seen for MVC apps isn't to put all the logic in the controllers. What you do is to create a "services" or "managers" layer that is called on by the controllers. A userService, for example, might have a function user = userService.login(name, password) It's also nice to abstract this service layer with some clean interfaces so that you can replace the underlying implementation, for example to m…
I prefer to put anything ORM-related inside the model. This way, I free views and controllers from the specifics of the platform and, as long as I keep the model API the same, I can move from one platform to another easily.
If userService.login method knows how to check a User's password, it's probably inextricably tied to the model and, therefore, part of it. Even if it's on a different module, it cannot be reused with a completely different model.
Re: MVC is dead, it's time to MOVE on
#93The best practices I've seen for MVC apps isn't to put all the logic in the controllers. What you do is to create a "services" or "managers" layer that is called on by the controllers. A userService, for example, might have a function user = userService.login(name, password) It's also nice to abstract this service layer with some clean interfaces so that you can replace the underlying implementation, for example to m…
I agree, I really like the "services" layer. I used it for years programming with Java/Spring and missed a lot when learning RoR. I think it is no coincidence that the two RoR real-world projects that I worked had enormous controllers. The service layer is great to orchestrate operations between models and I don´t know a reason for not using it.
Re: MVC is dead, it's time to MOVE on
#94> I don't wish to be misunderstood as implying that MVC is bad […] Since it was invented however, new programming techniques have become popular.
This doesn't make any sense to me.
The first problem is the blatant argumentum ad populum—just because other things are popular right now doesn't mean they're better.
The second problem is: I simply do not agree that we have new technologies that are so radically different and empowering from those that were available when MVC was invented. Indeed, Smalltalk (the language in which MVC was conceived) has late binding, dynamic typing and code blocks. I still think ‘modern’ scripting languages are playing catch-up with Smalltalk and LISP in terms of power, performance and clarity of expression.
Trygve Reenskaug (the inventor of MVC) later went on to develop DCI, a system which complements MVC, rather than replacing it wholesale. I'd recommend reading the Wikipedia page for more info, it's a coherent proposal and it seems to require the creation of far fewer classes and objects: http://en.wikipedia.org/wiki/Data,_context_and_interaction
Re: MVC is dead, it's time to MOVE on
#95Does 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.
I sort of evolved my own PHP framework pattern after I did my first few webdev jobs and identified the problem areas. This was before I had ever used a MVC framework.
Looking back at it now, it had everything your typical web MVC framework has, just slightly diffrent:
* Models, with cleanly encapsulated functionality, but without an ORM. I only built small websites, so all related database tables were managed by the same model.
* Controllers that handled all input and delegate it to models.
* Views in the form of HTML code following the controller code in the same file, but strictly separated.
* "Forms" that abstracted away the controller/view and input validation of forms in a neat, reusable package.
My point is that whatever you come up with that actually works well and lets you be productive will more-or-less resemble MVC.
Re: MVC is dead, it's time to MOVE on
#96MVC, more than other design patterns, is horribly abused. Developers should keep in mind its GUI roots. Here's my "is it MVC?" litmus test: How much of my code survives if I drastically change the view? For example, if I want to switch to a new desktop, web or text console interface, can I reuse much of the application? Of course, architecture changes this significantly (particularly web architecture), but still, if…
my rails apps pass this test with flying colors. Nearly all of my end points have at least 3 views. 1 for html, 1 for json (often used for ajax calls), and 1 for rss/atom.
JSON and RSS views don't make sense - in MVC, views are visual representations of data (the model). Views are how the user percieves the application. JSON and RSS are just different methods for representing data to be communicated to other systems.
Re: MVC is dead, it's time to MOVE on
#97It's amusing how the agile crowd slowly goes through the same learning curve that the java-guys rode 10 years ago. That's a good thing, though. They're at the verge of rediscovering SOA now and there's hope this incarnation will be less plagued by IOC-fluff and boilerplate, simply because the involved people have more of a hacking and less of an engineering background. I, for one, am looking forward to the "great sha…
How is SOA like teenage sex?
Everyone thinks everyone else is doing it, few are actually doing it and the ones that ARE doing it are doing it wrong.
Re: MVC is dead, it's time to MOVE on
#98[deleted]
Re: MVC is dead, it's time to MOVE on
#99Interesting post.
I've spent the last few years on an piece of software where the model and controller must be reusable between desktop, phone and tablet.
I started with a layered approach. Then I moved to MVC. After that I discovered MVVM. I finally ended up with an MVVM/Naked Objects hybrid.
The result is views that make changes to the model via command bindings, and respond to changes in the model via event bindings. The application (aka controller) is similarly bound to the model, and contains all business logic. It's clean, easy to maintain, and easy to test against and debug.
The views are different for each platform (desktop, phone and tablet), the model and application are re-used as-is.
I guess my point is that none of these approaches (MVC/MVVM/MVP/etc.) are bad. Each is good within a pretty small scenario window. The trick, probably learnt through experience, is knowning when to use which.
Re: MVC is dead, it's time to MOVE on
#100This sure looks like MVC, but they call the Controller "operations". The MVC abstraction has an issue with web applications, since the request-response cycle doesn't provide feedback as directly as the hardware-monitor-software cycle that the pattern was originally designed around. However, if the problem is that you are putting too much "logic" into your controllers, you should probably find a better place for it. I…
This article reminds me of Struts2
http://en.wikipedia.org/wiki/Apache_Struts
MVC with "action" (or event, similar semantics).
Speaking of Java/Spring-MVC approach, I tend to have a mix approach of Service and Repository (since DAO seems to be getting a lot of bad-rep, time to pick a new name :D).
Controller -> Service (SOAP) or Resource (REST) [although Resource could simply forward to Service as well)
or
Controller -> Repository (for specific entity that requires no interaction with other entities)
Unfortunately the Service layer is necessary in the situation where there are 2 or more domain models need to interact with each other.
This seems to help writing test-automations by splitting the tests into 2 categories:
1) End-to-End w/ mock repository
2) Integration only at Repository level using in-memory DB (Derby, H2)
By doing this, we were able to speed up the test significantly.
I believe in Rails, you're tied with ActiveRecord and would require real database (be it SQLite3). There may be open source libraries that can intercept AR calls and re-route it to either fake DB or just simply fake 'em all, but not sure how popular/complete they are.