MVC v. n-tier

[Mark]

I'm having trouble envisioning when I would choose to develop an ASP.NET web
application using the Model-View-Controller pattern rather than an n-tier
approach (code-behind, business object, data access tier, SQL Server).

I'd be interested to hear the situations that people have found MVC to be
the "right" solution for an ASP.NET application.

Thanks in advance.

Mark

 

[Guest]

I think in ASP.NET application, n-tier is more applicable.
Because there is some Microsoft Certified patterns for this architecture
using .NET resources.

But I prefer MVC. Because is more extensible.

In general, you must allocate same time for developing your .NET application
in both architecture. (Because in enterprise and complex J2EE application
also you must expand the ActionServlet and develope it.)

 

[Anders Norås [MCAD]]

I'm having trouble envisioning when I would choose to develop an ASP.NET

web
application using the Model-View-Controller pattern rather than an n-tier
approach (code-behind, business object, data access tier, SQL Server).

Using a MVC pattern does not rule out an n-tier architecture. If your
architecture will benefit the MVC pattern you should use it, but you should
still use business objects, a proper data access layer, service facades and
similar. Microsoft has a powerful MVC implemtation in the User Interface
Process (UIP) application block
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/uipab.asp).
I also suggest that you look at the other patterns and practies for
application architecture and design found here
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/listpattandpract.asp
for a complete overview of how to use UIP with an n-tier architecture.

Anders Norås
http://dotnetjunkies.com/weblog/anoras/

 

[Joerg Jooss]

I'm having trouble envisioning when I would choose to develop an
ASP.NET web application using the Model-View-Controller pattern
rather than an n-tier approach (code-behind, business object, data
access tier, SQL Server).

I'd be interested to hear the situations that people have found MVC
to be the "right" solution for an ASP.NET application.

MVC does not contradict n-tier at all. MVC is a pattern to decouple your UI
(presentation layer) from your model (domain layer). Layering is an approach
to decouple subsystems in general (and much more). MVC is basically a recipe
to enable proper layering.

Cheers,

 

[Guest]

You are right Mark ...... If we envision n-tier architecture as
'UserInterfaceLayer+BusinessObjectsLayer+DAtaAccessLayer' then this UIP
implementation of MVC is how you implement 'UserInterfaceLayer'.
'BusinessObjectsLayer' and 'DataAccessLayer' are independent of whether we
use UIP or not in 'UserInterfaceLayer'. So the best option according to me in
such situation would be to use n-tier architecture with UIP in
'UserInterfaceLayer'.

refer fig 1.1 on
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/uipab-ch01.asp

- Yatendra

 

[Guest]

i m sorry for confusion in names in my previous post I agree with Joerg and
express my views.

 

[RWBradley]

Just a note. Most ASP.NET/Code Behind developers don't develop n-tire applications. In most cases every page with its associated code behind file has a dependency on the data layer. So at best you could, maybe, call this a two-layer application. MVC helps you in the seperation of concerns which is vital to building a robust n-tier application. One note, MS's default is to put the model in the presentation layer, the model should be part of the business layer.

 

[CmdJerry]

This might help clarify your question: http://allthingscs.blogspot.com/2011/03/mvc-vs-3-tier-pattern.html