Alternative paradigms to MVC?
Moderator: General Moderators
Alternative paradigms to MVC?
MVC is a good, solid pattern. But I'm wondering: what other paradigms do you know of?
What are some other ways to organize an application?
I've heard of a variant called Controller-Action-View, which handles business logic slightly differently, but a Google search doesn't turn up much literature.
Also, when you use a lot of interactive JavaScript in your views, is it still correct to call them views? Maybe from the point of view of the back-end, yes, but from the point of view of interacting with the user, they can perform much more. What if you're building a mostly-JS application, where should the divisions of classic MVC fall?
I'm looking forward to hearing your thoughts and insights.
What are some other ways to organize an application?
I've heard of a variant called Controller-Action-View, which handles business logic slightly differently, but a Google search doesn't turn up much literature.
Also, when you use a lot of interactive JavaScript in your views, is it still correct to call them views? Maybe from the point of view of the back-end, yes, but from the point of view of interacting with the user, they can perform much more. What if you're building a mostly-JS application, where should the divisions of classic MVC fall?
I'm looking forward to hearing your thoughts and insights.
Re: Alternative paradigms to MVC?
An interesting alternative is an event based system. Vladsun proposed his own implementation in this thread - viewtopic.php?f=19&t=119817
Re: Alternative paradigms to MVC?
My web application are using ExtJS. So, my Views (as in MVC) are simple JSON formatted messages/data and my "real" views are client-side ExtJS views. Because a client-side View can't have direct access to the server-side Model one needs to put an intermediate communication layer - the one that formats output as JSON and reformats JSON input as a POST/GET-like input.mkz wrote:Also, when you use a lot of interactive JavaScript in your views, is it still correct to call them views? Maybe from the point of view of the back-end, yes, but from the point of view of interacting with the user, they can perform much more. What if you're building a mostly-JS application, where should the divisions of classic MVC fall?
There are 10 types of people in this world, those who understand binary and those who don't
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Alternative paradigms to MVC?
You may be thinking more about implementation differences than patterns here.mkz wrote:MVC is a good, solid pattern. But I'm wondering: what other paradigms do you know of?
What are some other ways to organize an application?
There has been tons on work done in the architecture area over the years -- almost all of it is variations on N-Tier and MVC. They get the basics right, then smart people give names to the variations they come up with (only to discard later). You might want to look into Supervising Controller and Passive View. Those are different spins on solving similar problems.mkz wrote:I've heard of a variant called Controller-Action-View, which handles business logic slightly differently, but a Google search doesn't turn up much literature.
Also, when you use a lot of interactive JavaScript in your views, is it still correct to call them views? Maybe from the point of view of the back-end, yes, but from the point of view of interacting with the user, they can perform much more. What if you're building a mostly-JS application, where should the divisions of classic MVC fall?
I'm looking forward to hearing your thoughts and insights.
And pushing part of the implementation into Javascript really makes little difference when it comes to separations and dependencies. Likewise making a system event-driven does not mean it is or is not MVC. Event driven as opposed to dispatched or a hybrid are implementation details.
I think a bigger question is why you are looking for "other paradigms"? Patterns are solutions to problems and you don't really state a problem you are having that MVC does not solve. Nor have you mentioned the much more common ways to divide PHP applications -- namely Transaction Script that removes any separations and Model-Presentation that combines Request and Response processing into a single script. Those are very common. Any framework that has a render() method in the Controller has already formalized a simpler "paradigm" than MVC.
(#10850)
Re: Alternative paradigms to MVC?
CQRS (coupled with Event Sourcing) is somewhat of a shift from MVC. Though they both have shared ideologies.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Alternative paradigms to MVC?
I was wondering when that buzzcronym was going to appear in the forums! Jenk is a rascal!Jenk wrote:CQRS (coupled with Event Sourcing) is somewhat of a shift from MVC. Though they both have shared ideologies.
I think the problem with CQRS for our crowd is that when the OP asked "What are some other ways to organize an application?" -- they were looking for a simpler way to implement their Javascript heavy web apps. CQRS is really just a more complex version of MVC where not only is the Presentation Layer divided (between Request and Response natures of that layer), but the Domain/Model Layer is divide between the Write/Command and Read/Query natures of that layer. This results in splitting the Model into two parts -- a write-only Command Model that is accessed by the Controller and a read-only Query Model that is accessed by the View. Very orthogonal!
But I don't think people are looking for an additional separation when MVC is already pushing them to do more than they already want to do.
From what I have been able to tell about CQRS, is that it is mainly an architecture to make-usable/kill DDD by moving it toward MVC (by sort of killing Entities). Events are used to synchronize the two Models in the case where the Query Model is a cache. I think this is what huge architectures like Google's search have been doing for a long time to get scalability. Essentially read and write are totally separate systems.
This does have some interesting opportunities for PHP developers. A simple approach might be to start dividing the interface of our Model classes in to read and write sections. The Controller would talk to the write half and the View would talk to the read half. That might lead to some interesting insights into what is actually going on in our Models (and apps for that matter). I think I might give that a try.
Thanks (as ever) Jenk!
(#10850)
Re: Alternative paradigms to MVC?
Great post 
The event sourcing side of it is what is the bigger shift from MVC. Instead of having objects that just simply interact with their domain counterparts, you use Commands to record every Event that the user performed. This is a much tougher way to implement a design, because it truly needs you to understand what the user's intent is when they perform an action. The rewards are fantastic though. And fun
The event sourcing side of it is what is the bigger shift from MVC. Instead of having objects that just simply interact with their domain counterparts, you use Commands to record every Event that the user performed. This is a much tougher way to implement a design, because it truly needs you to understand what the user's intent is when they perform an action. The rewards are fantastic though. And fun
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Alternative paradigms to MVC?
Yes, the event sourcing site is really interesting (not sure how fun because it can get tedious). But I also think the idea of splitting the Model is interesting as well. I think it may have benefits.
A nice thing about events in MVC is that it might be possible to implement Unit of Work over the top of MVC -- do all the registering and triggering in the app and then sort it all out and order/optimize at the end.
But as I said, these ideas add complexity to the application when I think people are looking for simplification.
A nice thing about events in MVC is that it might be possible to implement Unit of Work over the top of MVC -- do all the registering and triggering in the app and then sort it all out and order/optimize at the end.
But as I said, these ideas add complexity to the application when I think people are looking for simplification.
(#10850)
Re: Alternative paradigms to MVC?
How do the rewards differ from simply logging the user's actions in a normalized database table? Example, instantiate a logger object and pass it into objects which need to do some logging?Jenk wrote: The rewards are fantastic though
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Alternative paradigms to MVC?
Here's a little light reading:
http://martinfowler.com/eaaDev/EventSourcing.html

This is interesting stuff in relation to the shopping cart discussion (what ever happened to that?)
http://martinfowler.com/eaaDev/EventSourcing.html
This is interesting stuff in relation to the shopping cart discussion (what ever happened to that?)
(#10850)
Re: Alternative paradigms to MVC?
The very nature of event sourcing removes the need for any logging, as you'll have the Event Store as a ledger for every change ever made. You can (and should) have your event handlers to update a normalised database for the read portion of your app, which is simply a snapshot of the event store's latest output.josh wrote:How do the rewards differ from simply logging the user's actions in a normalized database table? Example, instantiate a logger object and pass it into objects which need to do some logging?Jenk wrote: The rewards are fantastic though
I think the biggest reward of CQRS/Event sourcing is the simplicity of integrating new events. Perhaps it is also just a breath of fresh air
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Alternative paradigms to MVC?
I would imagine the benefits are similar to that of AOP. You essentially remove cross-cutting concerns, logging being one of the best examples. You no longer need to pass a logger object into any layer, the events fired for the given object are intercepted and logging is done without the object ever having to know about the logger.How do the rewards differ from simply logging the user's actions in a normalized database table? Example, instantiate a logger object and pass it into objects which need to do some logging?
Cheers,
Alex
Re: Alternative paradigms to MVC?
Ok so the only difference between what you're talking about, and "simply making use of events"... is that what you're talking about involves using more events? I didn't read thru the given link yet but here's what I don't get:
"The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself."
Really? *every* state change is an event? So no more "setter" methods? Or do you build up an application like normal, and then sprinkle this in later?
As for the AOP comment, I get that it separates concerns, but so does dependency injection. I was more interested in the "payoff" you get from that rather than using dependency injection. Example, injecting a log into the constructor of an object keeps that object ignorant of the logger (but does introduce a new interface dependency), and vice versa... the logger is not dependent on the calling code.
With events though, how would would I stop a side effect from happening in just one instance of a class? For example, I can instantiate something twice, and pass just one of them the logger. How do you handle that in a straight forward way with events?
"The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself."
Really? *every* state change is an event? So no more "setter" methods? Or do you build up an application like normal, and then sprinkle this in later?
As for the AOP comment, I get that it separates concerns, but so does dependency injection. I was more interested in the "payoff" you get from that rather than using dependency injection. Example, injecting a log into the constructor of an object keeps that object ignorant of the logger (but does introduce a new interface dependency), and vice versa... the logger is not dependent on the calling code.
With events though, how would would I stop a side effect from happening in just one instance of a class? For example, I can instantiate something twice, and pass just one of them the logger. How do you handle that in a straight forward way with events?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Alternative paradigms to MVC?
Well ... a little context is in order. I don't get the impression that CQRS (and Event Sourcing) is for "us". It seems to be a reaction to Entity-itis within the DDD community. That is certainly the reaction to my attempts to do DDD in web apps. There may be some in the web app community that attempt to use a fully event driven system.josh wrote:"The fundamental idea of Event Sourcing is that of ensuring every change to the state of an application is captured in an event object, and that these event objects are themselves stored in the sequence they were applied for the same lifetime as the application state itself."
Really? *every* state change is an event? So no more "setter" methods? Or do you build up an application like normal, and then sprinkle this in later?
That leave me wondering whether CQRS is a step along the road of the evolution by the enterprise app guys (like DDD) that will lead to an architecture interesting/useful to us -- similar to what MVC Model 2 became.
So for example, what might a web app look like where the Front Controller triggered and Event rather than dispatched a Command? Maybe not much different, but what are the implications? How does the Base Event class in that case look different from a current base Action Controller class? How are all the services and helpers provided? How is the HTTP response rendered? Maybe just thinking about things differently leads to new options.
(#10850)
Re: Alternative paradigms to MVC?
In a word, yes. Every state change is captured in an event. The best comparison/metaphor for event sourcing is that of an accountant's ledger. Where the ledger is the event store, and each entry into the book (I.e. The deductions/additions) are the events. Another very good comparison/example is source control. You have a baseline value, and the events (revisions/adjustments) are a sequence of modifcations.
It's important to note that the above is Event Sourcing, not CQRS. But the two go very well together.
Look out for presentations by Greg Young and Udi Dahan. I attended the Domain Driven Design eXchange in London, and these two guys presented this really well.
It's important to note that the above is Event Sourcing, not CQRS. But the two go very well together.
Look out for presentations by Greg Young and Udi Dahan. I attended the Domain Driven Design eXchange in London, and these two guys presented this really well.