5

I've worked fairly extensively with the MVC framework cakephp, however I'm finding that I would rather have my pages driven by the multiple MVC than by just one MVC. My reason is primarily to maintain an a more DRY principle.

In CakePHP MVC: you call a URL which calls a single MVC, which then calls the layout. What I want is: you call a URL, it processes a layout, which then calls multiple MVC's per component/block of html on the page.

When you compare JavaScript components, AJAX, and server side HTML rendering, it seems the most consistent method for building pages is through blocks of components or HTML views. That way, the view block could be situated either on the server or the client.

This is technically my ONLY disagreement with the MVC model. Outside of this, IMHO MVC rocks!

My question is: What other RAD frameworks follow the same principles as MVC but are driven rather by the View side of MVC?

I've looked at Django and Ruby on Rails, yet they seems to be more Controller driven.

Lift/Scala appears to be somewhat of a good fit, but i'm interested to see what others exist.

Improve this question
3
  • @StuperUser @Shauna I've updated my question, perhaps you would like to revisit your response?
    – lordg
    Jun 16, 2011 at 18:45
  • I'm not sure of the details of CakePHP, but when you say "a URL which calls a single MVC", do you mean that a URL is routed to a single action?
    – StuperUser
    Jun 17, 2011 at 8:42
  • @StuperUser, yes, that is correct. The URL is routed to a Controller.Action, which then sends its results to the layout for rendering the rest of the page contents. At that point, its no longer MVC, but html templates pulled together.
    – lordg
    Jun 17, 2011 at 14:32

5 Answers 5

Reset to default
3

I think what you're thinking of is a concept called HMVC, which stands for Hierarchical Model View Controller.

What this means is that when you're rendering your view, you are able to dispatch a request to a completely different controller and return that view and echo it out. It behaves exactly like an ajax request, except it does not go through http, it goes through the framework and doesn't make an additional request.

This is not common in most frameworks, and the people who don't know about HMVC don't know what they're missing. It cleans up a lot of ugly patterns you see in regular MVC applications.

For example, you have a shopping cart on each page. Wouldn't it be nice to make a call to the shopping cart controller from within your code, and then allow it to handle the rendering and stuff? You can show different views for different states. Trying to do that in a class or a helper method is just a mess.

Anyways, what you came here for is a framework that works like this. The answer is Kohana. Here's the relevant docs.

Here's an example of it in use:
Request::factory('shopping_cart/display_items')->execute()-body;

Improve this answer
1
  • 1
    This is exactly what the OP is thinking... you are correct.
    – IamIC
    Jun 16, 2011 at 19:20
2

You probably won't find a flavour of MVC that involves a View doing anything.

As you know, in MVC the Views are supposed to be as "stupid" as possible to get good Separation of Concerns.

The request is routed to an action on a controller which does all of the logic on the model, and decides what to display and sends this to a view.

Since you can reuse Client code and views, I don't understand what aspect of MVC you're finding incompatible with the DRY principle?

If you want each page to take care of its own logic, ASP.NET has view-behinds and the Page model, but since it is essentially a web translation of WinForms, its state driven nature isn't really right for the Web (since HTTP is stateless), hence the current popularity and migration of developers to ASP.NET MVC.

Improve this answer
2
  • You are correct, the Views are stupid. In CakePHP you can have Elements, which are somewhat smarter Views. Inside the Element, you can fetch data from a Controller/Action and then produce the html with the rest of the Element. This is more DRY than the Controller > View method. It also has the advantage of being similar to View-Bindings that I've experienced (very limited at that) with what you say about ASP.NET.
    – lordg
    Jun 16, 2011 at 17:32
  • If the code in the example element is in a helper/service in the domain, that is called by a number of actions, it's just as re-usable. In fact, it should be, to prevent the anaemic domain anti-pattern. The controller actions should do as little business logic as possible and be concerned with choosing views based on the decisions made in the domain.
    – StuperUser
    Jun 16, 2011 at 17:42
1

As StuperUser said, MVC is based around the View being "stupid" or "thin," and honestly, it sounds like you might have a misunderstanding of MVC fundamentals somewhere (not necessarily, hard to do, in my experience, since MVC can be hard to understand if not explained well), if you're finding yourself copying code in controllers.

That said, you might want to take a look at the M-V-VM (Model, View, View-Model) structure that .Net's WPF and Silverlight technologies use (or at least used as of 3.5). It's based on MVC, but has some of its own rules and might be closer to what you're looking for.

Improve this answer
3
  • +1 for MVVM, I haven't used it, so didn't comment on it.
    – StuperUser
    Jun 16, 2011 at 17:48
  • I suspect its probably more how I'm explaining this question. M-V-VM is a good idea, yet I have not had much experience of it.
    – lordg
    Jun 16, 2011 at 18:01
  • @lordg - That's possible, too. :)
    – Shauna
    Jun 16, 2011 at 18:03
1

In CakePHP you can do what you ask for with requestAction. It is generally not advised because of performance issues, but works well, especially with cached content.

Improve this answer
1
  • Yes, you are correct, I've used it many times. Although it partially solves the problem, it suffers on performance without caching. An ideal system for me would be one that is built to do the requestAction style page building. This is what I'm looking for.
    – lordg
    Jun 17, 2011 at 14:35
1

ASP.NET MVC has a 'RenderAction' that you can call from within inline code in your view. I don't like it personally; I prefer to build compound models around a layout and let 'main view' models derive from it.

I may use a little builder or factory to instantiate the (compound) model to help me instantiate the composition. This is mostly to keep my controllers clean of knowledge about other sub-views.

Using this strategy I can have each partial view peel off it's own sub-model from the compound model or have the layout do it for a partial view.

Improve this answer
1
  • I found that most MVC system have the render action concept. They just are not built as a central mechanism to the systems. The systems appear to primarily be built around a primary Controller.Action for a url request, which is then fed off to the Layout render for the rest of the page build.
    – lordg
    Jun 17, 2011 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.