"MVC" architecture and ASP .NET

  • Thread starter Thread starter Peter Beck
  • Start date Start date
P

Peter Beck

Hi all -

In JSP/J2EE I've generally used a "Model-View-Controller" type of
architecture, with a "model" (a class representing the state of the
application (unique to each session)), a "controller" made up of a servlet
that is at the application level that redirects requests based on parameters
in the request, and a series of "views", namely JSPs generated by classes
called by the "controller". The calls from the controller generally perform
some manipulation on the model.

This has generally proved to be fairly robust and extensible - when a new
requirement arises it is usually a fairly easy matter to break it out into
each of these areas and add code as necessary.

What is the preferred approach with ASP .Net? The applications I've written
so far have comprised of a set of business objects and .aspx pages they
interact with (or that interact with them) but I'm wondering what a better
approach might be. Is it common in ASP .Net to have a non-visual
"controller"-type thread-safe application-level object that receives
requests from .aspx pages and in turn calls other objects that manipulate
the state of a "model" and/or call other .aspx pages?

In general I'd say that I prefer the ASP .Net development path to J2EE, but
I find the lack of emphasis on the application architecture in the
literature to be a little disconcerting. If anyone has some insights into
what I'm missing I'd appreciate it. Book references, links etc. are all
very welcome.

Regards,

Peter Beck
 
Theres a very good explanation available here that might help you get your
head around what could be perceived as MVC in .NET

http://www.dmbcllc.com/asp_mvc.aspx

The closest you will find is probably something called a front controller
model and this allows you to handle all the requests via a single entry
point, typically an ISAPI handler. Microsoft have a good explanation of this
available here.

http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/library/e
n-us/dnpatterns/html/ImpFrontControllerInASP.asp
--
Regards

John Timney
Microsoft Regional Director
Microsoft MVP
 
Even after solving a couple of problems in the sample code (http://msdn.microsoft.com/architect...s/dnpatterns/html/ImpFrontControllerInASP.asp) and looking at a working implementation at http://msdn.microsoft.com/asp.net/using/migrating/jspmig/resources/code/ , I'm trying to get the ASP.Net postback mechanism for Web Controls to work with this pattern (using Server.Transfer (or Server.Execute) to an .aspx page)
I think I might be missing something here.
Are Web Controls (and the ASP.Net page postback built-in mechanism) not meant to work with a different HttpHandler
Wouldn't it be correct to expect an implementation of an MVC pattern through an HttpHandler to work with Web Controls?(having the later just to handle UI events and higher level application actions handled by the former

Any thoughts and comments appreciate

Alfred
 
Back
Top