What are the main advantages of MVC pattern over the old fashioned 3-layer pattern

Question

I am contemplating about using an MVC pattern in my new project and I can clearly see the main advantage of being able to put the data layer (the model) a little closer to the presentation layer (the view), which will allow a little increase in application speed. But apart from performance stand point are there any other advantages of MVC over the view-logic-data layered type pattern?

EDIT: For those who's interested I just uploaded a sample PHP code that I created to test the use of MVC. I purposly omitted all the security checks to make the code a little easier to read. Please don't critisize it too much, because I know it could be a lot more refined and advanced, but nevertheless - it works!!! I will welcome questions and suggestions: Here is the link: http://www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.zip

Halibut

I am also in the stage of migrating to MVC from the conventional 3 tier applications. The question was handy – Khalid

possible duplicate of MVC Vs n-tier architecture – Jolty

Bert, I actually saw the qeustion you pointed out before I submitted mine, and it did partially gave me an answer of what an MVC was (answered by Mr/Ms 'void', which I rated "Up"), but I still couldn't tell of the MVC advantages. Mr arjan in this question gave me a very direct answer to what I was looking for. Thank you! – Halibut

Answer 1

The separation of concerns that's quoted as being an advantage of MVC is actually also an advance of a 3-layer/3-tier system. There too, the business logic is independent and can be used from different presentation tiers.

A main difference is that in classic MVC the model can have a reference back to the view. This means when data is updated the model can push this data back to possibly multiple views. The prime example is a desktop application where data is visualized in multiple ways. This can be as simple as a table and graph. A change in the table (which is a change in one view) is first pushed via the controller to the model, which then pushes it back to the graph (the other view). The graph then updates itself.

Since desktop development is on the decline, a lot of programmers have only come in touch with MVC in some web variant, e.g. via JSF in Java EE.

In those cases the model almost never has a reference to the view. This is because the web is mainly request/response based and after a request has been served, the server cannot send additional information. I.e. an update pushed from the model to the client would be meaningless. With reverse ajax/comet this is changing, but many web based MVC frameworks still don't fully utilize this.

Thus, in the case of web based MVC, the typical "triangle" between M, V and C is less there and that MVC variant is actually closer to an n-tier model than 'true' MVC is.

Also note that some web MVC frameworks have an intermediate plumbing part between M, V and C called a backing bean (Java/JSF) or code behind (ASP.NET). In JSF the controller is provided by the framework, and the view often doesn't bind directly to the model but uses this backing bean as an intermediary. The backing bean is very slim and basically just pre-fetches data from the model one way and translates model specific messages (e.g. exceptions) into view specific messages (e.g. some human readable text).

Rida

That's what I call a great answer! Right to the point! It took me 2 days of looking this up about MVC before I stumbled across this site, which already answered both of my questions in this subject! Thank you so much! Happy New Year! – Halibut

Also, would be beneficial information to others to look into MVP (Model-View-Presenter), a derivative of MVC, if you wish to further explorer the design patterns. – Halibut

Hmmm.. I also just thought about... If you use MVC as mostly unidirectional architecture, then you can't expect the same component resond to your function calls and events, which means that each components (or at least the View) would have to implement the input and the output interfaces (funcitons), which means writing a lot more code than you would have to in a layered architecture where each function can do both: receive and return. Am I wrong about it? – Halibut

It's not exactly like that. In MVC the entities from the model (E.g. a Customer object) can be directly bound to the view. Commands send from the view (e.g. a click on a button) are captured by the controller and delegated to the model. This is often just simple a method call, e.g. customer = CustomerService.getCustomer(customerID); Since the view is already bound to this customer, it will show the new values automatically when re-rendering (initiated by the controller) is being done. – Rida

Well, in Java EE it basically looks like this in the view: someTag value="#{someBean.someEntity}". It's a declarative binding in a way. someBean is stored in some scope (i.e. request- ,view- or conversation scope). After a call to the model (aka Service) returns, someEntity will be updated. The view only references someEntity. In this case, there thus is indeed some intermediate storage. This is the 'plumbing' part I talked about above. It belongs a bit to M, V and even C sometimes. – Rida

In order to bind a view directly to some "model" object, do you have to use some kind of intermediate data storage, such as XML or some sort of registry class that would reflect the updated data? And, if so, would this data storage belong inside of the "model" context or the "view" context? My guess is that since the "model" doesn't know or care about the view, but the reverse is opposite, the view knows and "cares" about the model, then the intermediate storage should belong inside of the model context... But you wouldn't put an entire database into XML, so how do you bind the view & model? – Halibut

Arjan, thanks as always! Sorry about messing up the order of the last 2 comments - I didn't expect you to answer this fast and I wanted to make a couple of changes to my comment, and my question ended up after your answer. :) – Halibut

Answer 2

Beside

• code reuse,
• separating of concerns,
• less coupling between the layers,

already mentioned by @bakoyaro and @arjan

i think that MVC is better than 3-tier when combined with the "convention over configuration" pattern. (i.e. "ruby on rails" or Microsofts "MVC for asp.net").

In my opinion this combination leads to to better and easier code maintanance.

In the first place it makes learning the mvc-framework a bit more difficuilt since you have to learn the conventions (a la controllers go into the controllers folder and must be named xxxxxcontroller)

But after you learned the conventions it is easier to maintain your own and foreign code.

Rhapsodist

Thank you! I will look into these conventions although I have yet to see anybody follow it in PHP, which is what I am using for my application. – Halibut

Your answer sounds as if you want to do mvc on your own. I prefer to you use a mvc-framework-libraries that implement "conviguration over convention" that does all the convention stuff for me. – Rhapsodist

Great advice! I will look for some PHP libraries to help me with that. Thank you! I already gave my vote to mr arjan though who I think asked my primary question the best, but I think you also deserve some credit for the additional info. Happy New Year! – Halibut

Answer 3

Forget increasing application speed by moving to MVC. I have found the biggest benefit to be ease of code reuse. Once you move to MVC, there are no dependencies on the presentation of your data or the storage of the actual data.

For example you could write a servlet that served up .jsp pages as your presentation layer one day, and the next day write a web service as another presentation layer to your existing Model and Controller. Like wise if you want or need to switch your DBMS. Since accessing the Model is completely separate from everything else, you would just need to re-write just your data access objects to return the data in a way your Controller can handle it.

By separating concerns into 3 distinct pieces, you also facilitate true unit testing. Your Presentation layer can be tested free of the Model or Controller, and vice-a-versa.

On a side note, I've often felt that the MVC abbreviation was inaccurate. Whenever I see it I think of it as View->Controller->Model. The presentation layer will never have DAO code in it, and the model will never have presentation logic in it. The Controller is forced to act as a go-between.

Holmgren

Well, I understand that MVC is a triangular pattern view->controller->model->"back to view" with mostly 1 way communication between components. And the 3-tier is a sequencial or linear pattern: view<->logic<->data with 2 way communication between each layer. What you said can also be implemented in the 3-layer pattern as long as you keep each layer separate and independent, but how is the MVC better? – Halibut

@techexpert: Your description of MVC is not the definition I know — not the one used in Cocoa or Rails, for sure. Your "view-logic-data" is more like what I know as MVC. – Gasper

Then i suggest you do some more research on this subject for your own benefit, because there is most definitely a difference. The answer from arjan is pointing this out. Also, wikipedia has description for both patterns 3-tier and MVC, in addition to other patterns. Peace! – Halibut

Answer 4

Where 3-tier separates presentation from business and data access, MVC is a presentation layer pattern which further separates Model (data) from View (screen) and Controller (input).

There is no choosing MVC over 3-tier/3-layered. Use them both.

Covet