Architecture More Suitable For Web Apps Than MVC

Architecture more suitable for web apps than MVC?

It all depends on your coding style. Here's the secret: It is impossible to write classical MVC in PHP.

Any framework which claims you can is lying to you. The reality is that frameworks themselves cannot even implement MVC -- your code can. But that's not as good a marketing pitch, I guess.

To implement a classical MVC it would require for you to have persistent Models to begin with. Additionally, Model should inform View about the changes (observer pattern), which too is impossible in your vanilla PHP page (you can do something close to classical MVC, if you use sockets, but that's impractical for real website).

In web development you actually have 4 other MVC-inspired solutions:

• Model2 MVC: View is requesting data from the Model and then deciding how to render it and which templates to use. Controller is responsible for changing the state of both View and Model.

• MVVM: Controller is swapped out for a ViewModel, which is responsible for the translation between View's expectations and Models's logic. View requests data from controller, which translates the request so that Model can understand it.

  Most often you would use this when you have no control over either views or the model layer.

• MVP (what php frameworks call "MVC"): Presenter requests information from Model, collects it, modifies it, and passes it to the passive View.

  To explore this pattern, I would recommend for you begin with this publication. It will explain it in detail.

• HMVC (or PAC): differs from Model2 with ability of a controller to execute sub-controllers. Each with own triad of M, V and C. You gain modularity and maintainability, but pay with some hit in performance.

Anyway. The bottom line is: you haven't really used MVC.

But if you are sick of all the MVC-like structures, you can look into:

• event driven architectures
• n-Tier architecture

And then there is always the DCI paradigm, but it has some issues when applied to PHP (you cannot cast to a class in PHP .. not without ugly hacks).

Reasons not to use MVC architecture for web application

One of the factors could be the statefulness of your web application. If it's a basic web application that gets everything from the server with a few JavaScript hooks such as client side validations, then the Rails type MVC is really great. I am not familiar with MVC on ASP.NET, but I've heard it's similar to that in Rails.

If the web application is really stateful, then a better approach would be to have a dual MVC layer - one on the client side, and the other for the server. The MVC on the server will mostly concern itself with authentication, authorization, churning out data in standard formats, etc. The client side MVC will concern itself with things such as DOM events, user actions, how they affect the application state, and how/when should data be requested/sent to the server.

MVC is just a way to organize code, just as BLL or DAL would do. MVC in Rails basically hides DAL altogether by using a set of conventions. Usually business logic resides in the models itself. However, if your application demands more complex BLL where object interactions can be intricate, then there's no reason why that BLL can't peacefully co-exist with the M in MVC.

Alternatives to NTier architecture for web apps

An alternative to the traditional N-tiered architecture is the Command-Query Responsibility Segregation (CQRS) architecture as discussed by Udi Dahan.

Like all architectural decisions you should really think about when to use it as discussed here

Personally, I tend to see a lot of "over architecture" in my software travels which can really over complicate matters and make things much more difficult to maintain and obviously cost a lot more too. You really need to think a lot about the business problem first rather than just picking an architecture.

Keep things as simple as possible for best results and easy refactoring.

ASP.NET MVC vs WebForms: speed and architecture comparison

• Development Speed: WebForms
• Performance Speed: MVC
• Ease of Use: WebForms (Typically)
• Unit Testing: MVC (Typically)

When NOT to use MVC in a Web Application?

I think that MVC is almost universally applicable to web applications that we see today. But it doesn't mean that the framework you use is always up to supporting the types of things that you want to do.

MVC is just a pattern that applies well to the web. In particular it applies well to the idea that an application is accessed in the following way:

• The user asks for some resource
• Some underlying data is retrieved from somewhere.
• A template is then applied to that data in order to show it to the user.

This is undeniably the way the web works, however most Web MVC frameworks start from the assumption that each user produces relatively few requests asking for big chunks of resources at a time. I have found that as web sites move frequent and smaller AJAX style requests lots of frameworks require some work to get them to play nicely because more and more of the 'view' part of MVC needs to be handled on the client. Framework support for this is nowhere near as mature as it is for server side views. However the central paradigm doesnt change much, and the central request - query - template loop is still there.

In short: MVC is a good way to think about the way your application works, but that doesn't mean you are going to find a pre written framework that handles all your needs.

Why is the MVC paradigm best suited for web applications?

Well, basically: separation of concerns on the usage level, not the physical level.

Quoting PoEAA on MVC

MVC splits user interface interaction into three distinct roles.

With MVC , you are separating presentation (V, C) from the domain logic (M) and you also separate UI behavior (C) from UI display (V). This is much more maintainable than intermingling all three concerns into one and it also fosters reuse and testing. It allows you to better tackle complexity.

This is nothing that just applies to Web Applications. It is suitable for any applications with domain logic and a UI. With that said, I wouldn't say MVC is the best-suited pattern for a web app though. If all you wanna do is put, say, a Contact Form on the web, then an all-in-one-page script would be sufficient. If you only got a bunch of static pages, MVC is overkill too. So like with any patterns, it depends on the problem you want to solve.

As for the n-tier, the "classic" MVC did not foresee it's use on the Web. With the presentation of the UI happening in the browser and the controller on a remote server, MVC on the web is always also a Multi-Tier architecture, hence the difference between usecase and physical in the beginning. MVC is just not concerned where it happens.

Also see:

• What is MVC and what are the advantages of it?
• MVC VS N-Tiers

Does KnockoutJS provide suitable architecture for building large web apps?

You can use partial views and share observables between them.

    var some_observable = ko.observable()

    var Model1 = function(something) {
        this.something_1 = something;
    };
    var Model2 = function(something) {
        this.something_2 = something;
    };

    var view_1 = Model1(some_observable);
    var view_2 = Model2(some_observable);

    ko.applyBindings(view_1, document.getElementById('some-id'));
    ko.applyBindings(view_2, document.getElementById('some-other-id'));

    <div id='some-id'>
        <input data-bind='value: something_1' />
    </div>
    <div id='some-other-id'>
        <input data-bind='value: something_2' />
    </div>

I've been using this aproach to maintain a list photos in a gallery application, where one view renders thumbnails and another view takes care of uploads.

What are the advantages of MVC over 3-Layer Architecture in web applications?

MVC is all about seperation of concerns - but deals with specifics in that the View is loosely-coupled to the model and controller; with 3-tier this is not explicitly required.

Yes - you can (and should) have all three tiers loosely-coupled but that's not explicitly required by 3-Tier; with MVC it is.

As an aside: MVC is a specific pattern that looks at a specific issue, I would be careful when referring to it as an "architecture".

An advantage of Microsofts ASP.NET MVC implementation is that is offers various integration points and flexibility which aren't so easily accessible with "standard" ASP.NET - which I guess you could say was/is traditionally used when build web-based 3-trie systesm in the MS space.

What other MVC-like design patterns/architectures are there for highly flexible applications?

I guess you are talking about software architecture (in contrast to hardware or system architecture).

Possibly the most important rule (I wouldn't call it pattern) is seperation of concerns. Meaning one component should handle exactly one task, only that task and the complete task. If you stick to that (which is harder than it seems). You'll have the basis for the plugability you mentioned, e.g. exchanging the UI. If your UI layer really does only UI, it can be replaced by something completely different.

If you are really talking big, like the mentioned GMail the concept of 'eventually consistent' becomes important. Classical applications are structured in a way that the user performs an action, say pressing a button. The application processes that action (e.g. saving data from a form in a database). And refreshes the GUI when it is done (e.g. replacing the 'save' button with an edit button. This linear processing has the benefit, that the user always sees a consistent state. If he turns around and searches the database he'll find his data right there. But this doesn't scale to well, when you have extremely high load on the system, because the optimum database for saving, is most of the time not the perfect database for searching. So some application do something like this: When the user hits the save button, the store the data in the fastes way possible (e.g. a database optimised for updates), set a marker that further processing is needed and refresh the gui. Now a separate process comes along to process the saved data, e.g. by updating special indexes or by storing it in a separate database that is optimized for searching. This second process might gather changes for many actions in order to improve performance.

With this design you can scale further, because you are separating concerns: storing and searching data are two different tasks, so they are split in two different component, which can in this extrem case work in parallel. For the user this means he might not immediately find the stuff he just saved, but he eventually will. Hence 'eventual consistency'

Edit: I forgot about the resources. Great books about application architecture are: Martin Fowlers 'Patterns of Enterprise Application Architecture'. For Patterns in general of course: 'Design Patterns' for Patterns concerning Messaging Architecture 'http://www.amazon.de/s/ref=nb_ss_eb?__mk_de_DE=%C5M%C5Z%D5%D1&url=search-alias%3Denglish-books&field-keywords=Enterprise+Integration&x=0&y=0'. I can't recommend any books on scalability, but 'Building Scalable Web Sites' was recommended to me. The architecture of various big applications (e.g. Twitter) is a topic of talks, presentations and papers, so you'll get lots of resources when you google > architecture twitter <.

---

Related Topics