Scaling MVC vs. Scaling multi-tier applications

As far as I know, multi-tier applications can be distributed to exploit scalability. That is, when your web application demands more resources than a single server can serve, you开发者_StackOverflow just distribute your application.

You can put the persistence tier in one server, the business tier in another and the presentation in a third server.

Furthermore, you can, for example, divide the business tier into many services and put each service in a separate server to cope with those many requests.

Because multi-tier applications, in essence, are components that communicate together by a middle-ware like SOAP, Sockets, .Net Remoting or RMI, it would be fairly easy to scale the application by further distribute its components.

The question is, what about an application that is designed using MVC architecture instead of N-Tier architecture?? As far as I know, models, views and controllers reside in a single machine, so how can someone distribute an MVC architectured web application??

Regards,

if you can call a web service in your controller to get data what stops you from calling a business layer that is on another system. My understanding of mvc is that it is meant to patternize application flow of the system. it does not mean end of business layer or having to put business and domain layers on the same system.

All part of application must be on one server. With MVC application you can scale architecture by copy iis instance. For example by default you have one computer with iis server and one site on it. For scale that you need to reorganize you instance like add some iis servers (the copy of you default) (it's call back-end servers) and add server witch balancing load to back-end (it's call front-end)

I'm currently working on this with CakePHP, which is an MVC framework. I've sharded the database for the system, which is ultimately the bottleneck in scaling.

While at the application level, the models, views and controller code exist on each instance of an application server. The controller and view levels work as they would normally. All the magic takes place in the code for the model. Before doing a read or write, the model will make a request to a directory server to figure out which shard the data is being stored on, or in the case of a new entry, which shard it should be added to.

How data is stored changes a bit though. I use MySQL as a key/value store and I don't use joins, similar what FriendFeed did.

Ultimately, this allows anyone familiar with the MVC design paradigm to come up to speed very quickly on the system. Developers working at the controller and view level don't need to even understand how the system is sharding (for the most part.)