4 replies to this topic

[Hamed]

3-tier architecture and MVC which one is better?
I am php programmer!

[Tom B]

Hi,

Pretty much every "MVC" implementation in PHP is actually closer to 3-tier anyway.

They make 2 fundamental mistakes in applying the MVC pattern:

1) They give the controller model level responsibility so it's fetching records, doing validation and other processing

2) The give the controller responsibility over its view and give the controller responsibility of passing model data to the view (in mvc the view requests its own data from the model)

While not quite 3 tier either, they're not MVC.

See: http://blog.astrumfu...ppreciated.html

and Model-View-Confusion part 1: Why the model is accessed by the view in MVC

Zend is probably closest to a true MVC framework as it only makes mistake #2.

[cipl]

MVC is better, MVC is the idea that you have three different pieces that work in unison to form a complex application. A car is a good real-world example of MVC. With a car you have two view: the interior and the exterior. Both take input from the controller: the driver, The brakes, steering wheel and the other controls represent the model: they take input from the controller(driver) and hand them off to the views(interior/exterior) for presentation.

[zeroradius]

Design patterns are not something that you use on a language by language basis; rather you use them on a case by case basis and often you may have to use more than one in a single instance. The MVC pattern for example is a compound pattern made up of three separate patterns . No pattern is better than another pattern, it all depends on your needs at the time.

[sam_coder]

I have SOME thoughts, but I look at this from the perspective of the enterprise. As I don't typically build things that run on a single computer or server.

So anyways, we tend to build our tiers on different systems all together. (the company I work for, I'm not implicating anyone specific in this forum)

For example,
the application might be running on IIS (I work with .NET primarily) on one server, whereas it interacts with the enterprise, talking to the business tier, on some other IIS server. What ever is behind that business tier, doesn't really matter to the application (though it could technically rely on other business tiers, or maybe a database server of some sort). That's the beauty of separating things like this. This level of abstraction, generally means that so long as you don't change your service boundaries, in any way, you can make significant changes to one tier, without affecting anything on another. (though how often does this happen in practice right? :))

I personally find MVC to be more of a client thing (application tier). And I wouldn't find that MVC itself provides the same benefit. I find MVC just forces you into a specific way of thinking, and in terms of maintainability, that's a great thing. I also find complex client applications or web applications or whatever, tend to get really unwieldy really fast. This is most of the area we experience most of the scope creep as well.

A possible MVC application example; I might set up a catalog controller. For which I make an index view, and a detail view. The model works in conjunction with the business tier, which lets say is set up exposing assets through SOAP services.

Outside the enterprise, I very much see it possible to build on similar concepts, using both types of approaches just the same. There's no reason I can think of that a person couldn't abstract their code in a very similar way, even if it were all part of the same application. In fact, I imagine many do...

But anyways, that's my two cents...