Page 1 of 3

Alternative paradigms to MVC?

Posted: Wed Oct 06, 2010 8:39 am
by mkz
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.

Re: Alternative paradigms to MVC?

Posted: Wed Oct 06, 2010 8:53 am
by Eran
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?

Posted: Thu Oct 07, 2010 8:52 am
by VladSun
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?
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.

Re: Alternative paradigms to MVC?

Posted: Thu Oct 07, 2010 7:19 pm
by Christopher
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?
You may be thinking more about implementation differences than patterns here.
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.
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.

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.

Re: Alternative paradigms to MVC?

Posted: Mon Oct 11, 2010 8:20 pm
by Jenk
CQRS (coupled with Event Sourcing) is somewhat of a shift from MVC. Though they both have shared ideologies.

Re: Alternative paradigms to MVC?

Posted: Mon Oct 11, 2010 9:51 pm
by Christopher
Jenk wrote:CQRS (coupled with Event Sourcing) is somewhat of a shift from MVC. Though they both have shared ideologies.
I was wondering when that buzzcronym was going to appear in the forums! Jenk is a rascal! ;)

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! :)

Re: Alternative paradigms to MVC?

Posted: Fri Oct 15, 2010 4:40 pm
by Jenk
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 :)

Re: Alternative paradigms to MVC?

Posted: Fri Oct 15, 2010 5:54 pm
by Christopher
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.

Re: Alternative paradigms to MVC?

Posted: Fri Oct 15, 2010 8:36 pm
by josh
Jenk wrote: The rewards are fantastic though
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?

Re: Alternative paradigms to MVC?

Posted: Sun Oct 17, 2010 12:28 am
by Christopher
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?)

Re: Alternative paradigms to MVC?

Posted: Mon Oct 18, 2010 3:44 am
by Jenk
josh wrote:
Jenk wrote: The rewards are fantastic though
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?
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.

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 :) Though I do find it rewarding to have an event responsible for its own data/actions, rather than through a controller and model. It's nice to just have an event and handler. :)

Re: Alternative paradigms to MVC?

Posted: Mon Oct 18, 2010 9:55 am
by alex.barylski
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?
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.

Cheers,
Alex

Re: Alternative paradigms to MVC?

Posted: Mon Oct 18, 2010 11:01 am
by josh
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?

Re: Alternative paradigms to MVC?

Posted: Mon Oct 18, 2010 12:05 pm
by Christopher
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?
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.

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.

Re: Alternative paradigms to MVC?

Posted: Mon Oct 18, 2010 4:09 pm
by Jenk
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.