MVC application. How does mult-tier architecture fit in?

Question

I am new to the concept of MVC and multi-tiered web architecture. I developing a PHP application and am using one of the available MVC frameworks. My question is as follows:

From what I understand, MVC in and of itself is not considered a multi-tier architecture. I can understand how using MVC alone is a step up from taking an unstructured approach, but I was contemplating how a simple 3-tier architecture would fit in? Would MVC reside in the presentation layer? What are the merits of adding a tiered approach? From what I gather, with MVC alone there are no explicit data objects responsible for retrieving data from the database and this is usually stuffed into the model. Likewise the business logic, which in a 3-tiered architecture would reside in a 'business-layer' (or whatever you want to call it), can be stuffed into the controller.

Is my understanding somewhat correct? I know I asked a lot of questions, but I would like to hear you discuss how you incorporated an n-tier architecture into your MVC framework (PHP or otherwise) as I assume that the two are not mutually exclusive. Thanks!

Intrusive

Possible duplicates: #900303, #2843811, #14451944 – Holiness

Answer 1

M) M is your model. This is generally living in your business layer or the layer just behind your presentation layer. Many people don't like the presentation layer to have any knowledge of the business layer though and so they further abstract that by having what is called a ViewModel. These frequently are DTO (data transfer objects) that loosely map to your Domain model. For me (.net guy) there are tools such as AutoMapper to make the conversion from Domain Model to View Model.

V) V is your view. The view is your presentation layer. This is the actual HTML or PHP code that the user directly touches and interacts with. The view should be as light as possible (meaning no logic if possible). Try to keep any sort of if/then type scenarios out of the view and stick to just displaying and collecting data. Present a ViewModel to your web designers so that they don't contaminate your DomainModel.

C) C is your controller. This is much like a co-ordinator. It takes data from your view and makes sure it gets to the right back end function/method for processing that data. It also co-ordinates data from the back end on it's way to the front end.

Where multi-tier design concepts come in is behind the Presentation layer (where is where MVC is primarily). When the controller is taking data from the view and passing it back to the back end it (if you follow DDD or Domain Driven Design) would pass the data to an application service (a class that co-ordinates back end matters). The service might further push the data into a Repository layer (which is a class that speaks to the database, filesystem, web services, etc. - any infrastructure stuff). DDD is a big topic but will get your head around the n-tier approach and how it works with MVC.

While researching this topic take a look at IoC (inversion of control), DI (dependency injection), TDD (test driven development), and as many patterns as possible (facade, factory, etc.).

Molt

Answer 2

In general, business logic should not be in the Controller - you'd end up with massive controllers if you followed this pattern. The Model basically houses all your non-presentation layers ... data access, business logic, and business entity objects. Your controller prepares the business data for the view.

Aesthesia