If they were the same, then anybody with a 3 tier architecture would by definition have implemented MVC. Since that would be a false statement, we can safely say that they are not the same thing.
MVC has specific architectural patterns as to how the tiers interact that differ from a straight 3 tier architecture.
Let me try to phrase it a different way... 3-tier architecture is a system architecture pattern, while MVC is an application architecture pattern.
When people say "3-tiered architecture," they are typically refering to the major processing parts of a system (i.e. UI, back-end, and database). This goes back to the client/server days when client apps were completely separate from server-side processing.
Looking at it from a web standpoint, you have several ways you can think about it, but the primary view is that the HTML output is the UI, and the code-behind is the "back-end," as you might deduce. Not a big deal, really, but as web development has grown
over the years, sometimes the distinction between the two gets blurred.
MVC has to do with applications. One way that helps people learn the difference is to consider hardware: In a "good" 3-tiered system, you'll have different hardware for each tier; whereas with MVC, everything will most likely be on one system -- unless you're
clustering, but we won't get into that. Of course, this isn't always the case, but it's a simplistic way to look at it and visualize the difference.
Let me try to phrase it a different way... 3-tier architecture is a system architecture pattern, while MVC is an application architecture pattern.
When people say "3-tiered architecture," they are typically refering to the major processing parts of a system (i.e. UI, back-end, and database). This goes back to the client/server days when client apps were completely separate from server-side processing.
Looking at it from a web standpoint, you have several ways you can think about it, but the primary view is that the HTML output is the UI, and the code-behind is the "back-end," as you might deduce. Not a big deal, really, but as web development has grown
over the years, sometimes the distinction between the two gets blurred.
MVC has to do with applications. One way that helps people learn the difference is to consider hardware: In a "good" 3-tiered system, you'll have different hardware for each tier; whereas with MVC, everything will most likely be on one system -- unless you're
clustering, but we won't get into that. Of course, this isn't always the case, but it's a simplistic way to look at it and visualize the difference.
Hope that helps!
I have a hunch that tdnxxx444 meant 3-layered, not 3-tiered, which are commonly mixed to mean the same thing.
I think that MVC is an odd form of n-layered architecture. You have three parts of sorts, but it almost seems like the business and data layers are merged into the model, and the controller is the part that ties together the presentation (view) from that
model. Truthfully, it's not my favorite architecture.
An n-layered architecture is where an application is split into multiple distinct, logical layers. Usually this is presentation, business, and data, but there may be more, and there may be sublayers within those major three.
Generally, in the strict form of this architecture, the presentation only communicates with the business layer, which only communicates with the presentation and data layers, and the data layer only communicates with the business layer. Basically, each layer
should only communicate with the layer directly above and below it.
When people say "3-tiered architecture," they are typically refering to the major processing parts of a system (i.e. UI, back-end, and database). This goes back to the client/server days when client apps were completely separate from server-side processing.
Looking at it from a web standpoint, you have several ways you can think about it, but the primary view is that the HTML output is the UI, and the code-behind is the "back-end," as you might deduce.
Perhaps i'm misinterpreting you remark, but it appears your indicating:
UI layer = HTML output
Business layer = Web page code-behind
Data layer = Database
The prevailing view is that business logic is its own layer and does not go in web page code-behind.
Web page code-behind is still part of the UI layer. The code-behind may use information it receives from the business layer as it helps to construct the final html that is emitted.
Perhaps i'm misinterpreting you remark, but it appears your indicating:
UI layer = HTML output
Business layer = Web page code-behind
Data layer = Database
The prevailing view is that business logic is its own layer and does not go in web page code-behind.
Web page code-behind is still part of the UI layer. The code-behind may use information it receives from the business layer as it helps to construct the final html that is emitted.
When you're talking about a 3-tiered architecture, this is about right. If you really want to get technical with it, the UI layer consists of two parts -- UI and UI process components, which includes the ASPX and code-behind. The business layer should be
separate from code-behind. I apologize. I did state this wrong -- I am a very big proponent of keeping as much out of the code-behind as possible. In effect, the code-behind should do nothing but merging the UI components into objects and passing them to/from
the business layer.
I think that MVC is an odd form of n-layered architecture. You have three parts of sorts, but it almost seems like the business and data layers are merged into the model, and the controller is the part that ties together the presentation (view) from that model.
Truthfully, it's not my favorite architecture.
An n-layered architecture is where an application is split into multiple distinct, logical layers. Usually this is presentation, business, and data, but there may be more, and there may be sublayers within those major three.
You're correct about MVC. The model is everything that isn't view and controller; the view is the UI and UI process components, as I mentioned in my other post; and, in .NET, the controller is handled almost exclusively by the framework. You can build components
to work in that space, but most people don't. In the .NET world, the controller line is blurred a lot because of random features that help increase productivity. These productivity gains come at a cost, and part of that cost is confusion with abstract pattern
like this one.
MVC is a fantastic idea, but you have to understand it, first. A lot of people think they know what it is, but don't really understand what each part is. It seems like a lot of people take the three parts and assume their responsibilities based on their
title, which leads to invalid perceptions. MVC was never ment to be a system architecture pattern. MVC is an application pattern. Every physical layer of your system should implement its own MVC. In a web world, the UI and business logic/data access layers
are typically in the same app, so that doesn't really fit, but if you take the client/server example, think about it this way: the client has an obvious view (UI), the controller is basically covered by the framework, and the model includes whatever classes
you need to make it work. On the server side, you'll need another UI (not for the user, but for the client app to talk to the server); again, the controller is basically covered by the framework; and, just like the client, the model is everything in-between
-- the meat of your system.
As for multiple layers, I completely agree. There can be tons of layers. It's all about the perspective you take when looking at an application. That's why I hate the word "architecture." Depending on your perspective, it can mean a lot of different things.
You should never use the word "architecture" without giving it scope (i.e. system architecture = highest level system components (i.e. app, database) and application architecture = UI/UI process, domain objects, business logic, service layer, data access).
You can break any architecture down into innumerable layers, as you mentioned.
Remember, these patterns are simply the consolidated experience of others into words and pictures. They aren't supposed to be word for word in every system. Take them and morph them as appropriate. Just make sure you understand why it works the way it does
before you change it. Talk to others about patterns to understand them completely and, where necessary, put your thoughts on your situation out there so others can put their insight into the approach you want to take. Getting insight from others is invaluable,
no matter what level you're at technically or professionally.
devbanana> I think that MVC is an odd form of n-layered architecture. You have three parts of sorts...
This is not correct. The three nodes is just a misleading similarity and the two models are not even at the same process level (as flanakin is also implying). Below some explanation.
flanakin> You're correct about MVC. The model is everything that isn't view and controller; the view is the UI and UI process components...
No, MVC is a full-fledged self standing design pattern applying to a specific single component, the GUI component, in an interactive application. Layering instead is an
architectural pattern, applying to components organization and inter-relationship. (I know you have said something of this with different words, i'm just taking the start from here.)
Even if you take those patterns not too strictly (which i agree should be the case for patterns in general, as per the "apply the patterns gently" agile principle), these two models do not share any similarity in their very structure. Layering is about decoupling
and each layer just depending on the layer below it. MVC instead is about input-process-output in an interactive and event-driven GUI, and here the three nodes are much more coupled and the flow of messages is much more complicated than a linear flow.
A bit of history might make things more clear to get where MVC fits: First came the input-processing-output model (IPO). Then came model-view-controller (MVC) as a rivised IPO to address interactive event-driven applications. Finally came the web, where
inspired by MVC they invented Model 2...
flanakin> Every physical layer of your system should implement its own MVC.
And i'm afraid this is also incorrect. You need MVC for the GUI component only. You won't wrap any library into MVC, because MVC is about interaction, not simple method invocation (even in the context of a workflow). MVC is about interactive event-driven
scenarios only.
> the client has an obvious view (UI), the controller is basically covered by the framework, and the model includes whatever classes you need to make it work
And i cannot agree on this neither. A web oriented version of MVC is Model 2, where you have pages as view, some http handler receiving requests as controller, and a model as a library below, possibly on top of the business layer. This is Model 2, inspired
by MVC, sharing a common terminology, yet a distinct pattern with a different internal flow. A real MVC pertains to the GUI only, and that, in a web application, is html/css/scripts, that is what runs in the context of the client browser. That's the GUI.
In other words. In a web application we can furtherly split the so called Presentation Layer in two distinct layers. There's an Application Layer, that is the web page's server-side code (code-inline and code-behind). And there's a strictu sensu Presention
Layer, that is the client code getting to the browser. That's the GUI, and that's where you might need MVC.
Btw, MVC is a peculiar model, so not to be confused with widgets and gadgets either...
I don't think it is incorrect to think of MVC as more than a standard design pattern. A design pattern describes something a bit more atomic typically.
I also do not agree with the distinction you make between client code and server code, nor your distinguishing "model 2" from any other MVC implementation. I think model 2 is the same model, either poorly implemented or implemented with different understanding
of what a user is. In a less sacrificed web MVC, if you take away the web part of it, you are still left with the M and the C, and you can create a V in a completely different GUI technology. For example, you could create a windows forms app, WAP app, or
even, as a stretch, a telephony app. All of those different interfaces could connect to the M and the C without modification to the Controller.
It really just depends on how you define the user. Is the user a human being who might want to access your application using any number of technologies, or is the user a human being using a specific browser, or a specific type of browser?
If you think of just the browser as containing virtually all of the MVC (i.e. some ajax-centric MVC ideology), I think that is only appropriate for applications where there is very strict control over the browser, and the browser is necessarily immutable.
The "model 2" you are describing is to me actually just a poorly implemented "regular" mvc that has been perpetuated by certain platforms that shall remain nameless. I would call the web page, http controller, library an anti-pattern, or possibly more accurately
simply a compromised or weak MVC.
Of course, this is all very subjective. A lot of people seem happy with web / http-aware servlet / db as MVC. I don't really see the benefit. I think that it has grown too tall for its clothes and people overuse this type of MVC because they hear it's
good. But realistically, such an MVC is probably only appropriate in a small portion of apps.
[quote user="LudovicoVan"] flanakin> Every physical layer of your system should implement its own MVC.
And i'm afraid this is also incorrect. You need MVC for the GUI component only. You won't wrap any library into MVC, because MVC is about interaction, not simple method invocation (even in the context of a workflow). MVC is about interactive event-driven
scenarios only.
> the client has an obvious view (UI), the controller is basically covered by the framework, and the model includes whatever classes you need to make it work
And i cannot agree on this neither. A web oriented version of MVC is Model 2, where you have pages as view, some http handler receiving requests as controller, and a model as a library below, possibly on top of the business layer. This is Model 2, inspired
by MVC, sharing a common terminology, yet a distinct pattern with a different internal flow. A real MVC pertains to the GUI only, and that, in a web application, is html/css/scripts, that is what runs in the context of the client browser. That's the GUI.
In other words. In a web application we can furtherly split the so called Presentation Layer in two distinct layers. There's an Application Layer, that is the web page's server-side code (code-inline and code-behind). And there's a strictu sensu Presention
Layer, that is the client code getting to the browser. That's the GUI, and that's where you might need MVC.
Btw, MVC is a peculiar model, so not to be confused with widgets and gadgets either...
You're way off on the idea that MVC only applies to GUI environments. I do agree that it probably shouldn't be tacked on to a library, but MVC was never intended to be for user-facing systems only. Think about it this way: Let's say you have a search engine
like Live.com, you'll obviously have the standard user interface, but you will most likely have a service-based interface so that other systems can be developed against that infrastructure. This is one of the main proponents
for MVC. Because the view is abstracted away from the model and controller, a new view can be added without having to rewrite the logic tying the two together. If done correctly, this would be an ideal example of MVC at its best.
You have to remember that these patterns aren't just for show and tell, there's a real reason for them being around. Part of the reason MVC is around is because, when the game changes -- and it always does -- the abstractions can save you an immense amount
of time, effort, and, most importantly, money.
tdnxxx444
Member
120 Points
33 Posts
Is 3 tier architecture = MVC?
Aug 23, 2006 10:43 PM|LINK
I've read in various places from different people that MVC is the same in 3 tier architecture in that:
M = DL
V = Presentation / UIL
C = Business Layer
Is this true? For some reason, I feel it is not.
mbanavige
All-Star
134971 Points
15423 Posts
ASPInsiders
Moderator
MVP
Re: Is 3 tier architecture = MVC?
Aug 24, 2006 01:46 AM|LINK
If they were the same, then anybody with a 3 tier architecture would by definition have implemented MVC. Since that would be a false statement, we can safely say that they are not the same thing.
MVC has specific architectural patterns as to how the tiers interact that differ from a straight 3 tier architecture.
http://en.wikipedia.org/wiki/Three-tier_(computing)
flanakin
Participant
1911 Points
384 Posts
Re: Is 3 tier architecture = MVC?
Aug 24, 2006 04:08 PM|LINK
Let me try to phrase it a different way... 3-tier architecture is a system architecture pattern, while MVC is an application architecture pattern.
When people say "3-tiered architecture," they are typically refering to the major processing parts of a system (i.e. UI, back-end, and database). This goes back to the client/server days when client apps were completely separate from server-side processing. Looking at it from a web standpoint, you have several ways you can think about it, but the primary view is that the HTML output is the UI, and the code-behind is the "back-end," as you might deduce. Not a big deal, really, but as web development has grown over the years, sometimes the distinction between the two gets blurred.
MVC has to do with applications. One way that helps people learn the difference is to consider hardware: In a "good" 3-tiered system, you'll have different hardware for each tier; whereas with MVC, everything will most likely be on one system -- unless you're clustering, but we won't get into that. Of course, this isn't always the case, but it's a simplistic way to look at it and visualize the difference.
Hope that helps!
www.michaelflanakin.com
devbanana
Member
105 Points
21 Posts
Re: Is 3 tier architecture = MVC?
Aug 24, 2006 09:16 PM|LINK
I have a hunch that tdnxxx444 meant 3-layered, not 3-tiered, which are commonly mixed to mean the same thing.
I think that MVC is an odd form of n-layered architecture. You have three parts of sorts, but it almost seems like the business and data layers are merged into the model, and the controller is the part that ties together the presentation (view) from that model. Truthfully, it's not my favorite architecture.
An n-layered architecture is where an application is split into multiple distinct, logical layers. Usually this is presentation, business, and data, but there may be more, and there may be sublayers within those major three.
Generally, in the strict form of this architecture, the presentation only communicates with the business layer, which only communicates with the presentation and data layers, and the data layer only communicates with the business layer. Basically, each layer should only communicate with the layer directly above and below it.
mbanavige
All-Star
134971 Points
15423 Posts
ASPInsiders
Moderator
MVP
Re: Is 3 tier architecture = MVC?
Aug 25, 2006 12:26 AM|LINK
Perhaps i'm misinterpreting you remark, but it appears your indicating:
UI layer = HTML output
Business layer = Web page code-behind
Data layer = Database
The prevailing view is that business logic is its own layer and does not go in web page code-behind.
Web page code-behind is still part of the UI layer. The code-behind may use information it receives from the business layer as it helps to construct the final html that is emitted.
flanakin
Participant
1911 Points
384 Posts
Re: Is 3 tier architecture = MVC?
Aug 25, 2006 02:34 PM|LINK
When you're talking about a 3-tiered architecture, this is about right. If you really want to get technical with it, the UI layer consists of two parts -- UI and UI process components, which includes the ASPX and code-behind. The business layer should be separate from code-behind. I apologize. I did state this wrong -- I am a very big proponent of keeping as much out of the code-behind as possible. In effect, the code-behind should do nothing but merging the UI components into objects and passing them to/from the business layer.
www.michaelflanakin.com
flanakin
Participant
1911 Points
384 Posts
Re: Is 3 tier architecture = MVC?
Aug 25, 2006 02:53 PM|LINK
You're correct about MVC. The model is everything that isn't view and controller; the view is the UI and UI process components, as I mentioned in my other post; and, in .NET, the controller is handled almost exclusively by the framework. You can build components to work in that space, but most people don't. In the .NET world, the controller line is blurred a lot because of random features that help increase productivity. These productivity gains come at a cost, and part of that cost is confusion with abstract pattern like this one.
MVC is a fantastic idea, but you have to understand it, first. A lot of people think they know what it is, but don't really understand what each part is. It seems like a lot of people take the three parts and assume their responsibilities based on their title, which leads to invalid perceptions. MVC was never ment to be a system architecture pattern. MVC is an application pattern. Every physical layer of your system should implement its own MVC. In a web world, the UI and business logic/data access layers are typically in the same app, so that doesn't really fit, but if you take the client/server example, think about it this way: the client has an obvious view (UI), the controller is basically covered by the framework, and the model includes whatever classes you need to make it work. On the server side, you'll need another UI (not for the user, but for the client app to talk to the server); again, the controller is basically covered by the framework; and, just like the client, the model is everything in-between -- the meat of your system.
As for multiple layers, I completely agree. There can be tons of layers. It's all about the perspective you take when looking at an application. That's why I hate the word "architecture." Depending on your perspective, it can mean a lot of different things. You should never use the word "architecture" without giving it scope (i.e. system architecture = highest level system components (i.e. app, database) and application architecture = UI/UI process, domain objects, business logic, service layer, data access). You can break any architecture down into innumerable layers, as you mentioned.
Remember, these patterns are simply the consolidated experience of others into words and pictures. They aren't supposed to be word for word in every system. Take them and morph them as appropriate. Just make sure you understand why it works the way it does before you change it. Talk to others about patterns to understand them completely and, where necessary, put your thoughts on your situation out there so others can put their insight into the approach you want to take. Getting insight from others is invaluable, no matter what level you're at technically or professionally.
www.michaelflanakin.com
LudovicoVan
Star
9692 Points
1935 Posts
Re: Is 3 tier architecture = MVC?
Aug 25, 2006 04:28 PM|LINK
Getting deeper on MVC:
devbanana> I think that MVC is an odd form of n-layered architecture. You have three parts of sorts...
This is not correct. The three nodes is just a misleading similarity and the two models are not even at the same process level (as flanakin is also implying). Below some explanation.
flanakin> You're correct about MVC. The model is everything that isn't view and controller; the view is the UI and UI process components...
No, MVC is a full-fledged self standing design pattern applying to a specific single component, the GUI component, in an interactive application. Layering instead is an architectural pattern, applying to components organization and inter-relationship. (I know you have said something of this with different words, i'm just taking the start from here.)
Even if you take those patterns not too strictly (which i agree should be the case for patterns in general, as per the "apply the patterns gently" agile principle), these two models do not share any similarity in their very structure. Layering is about decoupling and each layer just depending on the layer below it. MVC instead is about input-process-output in an interactive and event-driven GUI, and here the three nodes are much more coupled and the flow of messages is much more complicated than a linear flow.
A bit of history might make things more clear to get where MVC fits: First came the input-processing-output model (IPO). Then came model-view-controller (MVC) as a rivised IPO to address interactive event-driven applications. Finally came the web, where inspired by MVC they invented Model 2...
flanakin> Every physical layer of your system should implement its own MVC.
And i'm afraid this is also incorrect. You need MVC for the GUI component only. You won't wrap any library into MVC, because MVC is about interaction, not simple method invocation (even in the context of a workflow). MVC is about interactive event-driven scenarios only.
> the client has an obvious view (UI), the controller is basically covered by the framework, and the model includes whatever classes you need to make it work
And i cannot agree on this neither. A web oriented version of MVC is Model 2, where you have pages as view, some http handler receiving requests as controller, and a model as a library below, possibly on top of the business layer. This is Model 2, inspired by MVC, sharing a common terminology, yet a distinct pattern with a different internal flow. A real MVC pertains to the GUI only, and that, in a web application, is html/css/scripts, that is what runs in the context of the client browser. That's the GUI.
In other words. In a web application we can furtherly split the so called Presentation Layer in two distinct layers. There's an Application Layer, that is the web page's server-side code (code-inline and code-behind). And there's a strictu sensu Presention Layer, that is the client code getting to the browser. That's the GUI, and that's where you might need MVC.
Btw, MVC is a peculiar model, so not to be confused with widgets and gadgets either...
-LV
TAsunder
Participant
1001 Points
215 Posts
Re: Is 3 tier architecture = MVC?
Aug 25, 2006 11:40 PM|LINK
I don't think it is incorrect to think of MVC as more than a standard design pattern. A design pattern describes something a bit more atomic typically.
I also do not agree with the distinction you make between client code and server code, nor your distinguishing "model 2" from any other MVC implementation. I think model 2 is the same model, either poorly implemented or implemented with different understanding of what a user is. In a less sacrificed web MVC, if you take away the web part of it, you are still left with the M and the C, and you can create a V in a completely different GUI technology. For example, you could create a windows forms app, WAP app, or even, as a stretch, a telephony app. All of those different interfaces could connect to the M and the C without modification to the Controller.
It really just depends on how you define the user. Is the user a human being who might want to access your application using any number of technologies, or is the user a human being using a specific browser, or a specific type of browser?
If you think of just the browser as containing virtually all of the MVC (i.e. some ajax-centric MVC ideology), I think that is only appropriate for applications where there is very strict control over the browser, and the browser is necessarily immutable.
The "model 2" you are describing is to me actually just a poorly implemented "regular" mvc that has been perpetuated by certain platforms that shall remain nameless. I would call the web page, http controller, library an anti-pattern, or possibly more accurately simply a compromised or weak MVC.
Of course, this is all very subjective. A lot of people seem happy with web / http-aware servlet / db as MVC. I don't really see the benefit. I think that it has grown too tall for its clothes and people overuse this type of MVC because they hear it's good. But realistically, such an MVC is probably only appropriate in a small portion of apps.
flanakin
Participant
1911 Points
384 Posts
Re: Is 3 tier architecture = MVC?
Aug 26, 2006 02:53 AM|LINK
And i'm afraid this is also incorrect. You need MVC for the GUI component only. You won't wrap any library into MVC, because MVC is about interaction, not simple method invocation (even in the context of a workflow). MVC is about interactive event-driven scenarios only.
> the client has an obvious view (UI), the controller is basically covered by the framework, and the model includes whatever classes you need to make it work
And i cannot agree on this neither. A web oriented version of MVC is Model 2, where you have pages as view, some http handler receiving requests as controller, and a model as a library below, possibly on top of the business layer. This is Model 2, inspired by MVC, sharing a common terminology, yet a distinct pattern with a different internal flow. A real MVC pertains to the GUI only, and that, in a web application, is html/css/scripts, that is what runs in the context of the client browser. That's the GUI.
In other words. In a web application we can furtherly split the so called Presentation Layer in two distinct layers. There's an Application Layer, that is the web page's server-side code (code-inline and code-behind). And there's a strictu sensu Presention Layer, that is the client code getting to the browser. That's the GUI, and that's where you might need MVC.
Btw, MVC is a peculiar model, so not to be confused with widgets and gadgets either...
You're way off on the idea that MVC only applies to GUI environments. I do agree that it probably shouldn't be tacked on to a library, but MVC was never intended to be for user-facing systems only. Think about it this way: Let's say you have a search engine like Live.com, you'll obviously have the standard user interface, but you will most likely have a service-based interface so that other systems can be developed against that infrastructure. This is one of the main proponents for MVC. Because the view is abstracted away from the model and controller, a new view can be added without having to rewrite the logic tying the two together. If done correctly, this would be an ideal example of MVC at its best.
You have to remember that these patterns aren't just for show and tell, there's a real reason for them being around. Part of the reason MVC is around is because, when the game changes -- and it always does -- the abstractions can save you an immense amount of time, effort, and, most importantly, money.
www.michaelflanakin.com