Josh Gough

<July 2008>
SuMoTuWeThFrSa
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789


Navigation

Subscriptions

Post Categories



Wednesday, July 05, 2006 - Posts

Modular ASP.NET 2.0 Architectures?

Modular ASP.NET 2.0 Architectures?

 

 

I'm interested in hearing how other developers are going about designing ASP.NET 2.0 applications that are modular. Here's an example of what I mean:

 

 

Core Web App: top-level MasterPage, BasePage, BaseControl, Authentication/Authorization, Common DAL classes / UI Code / Error handling page / Logging facilities

Shared Components: CSS, Images, JavaScript libraries, Common ASCX/Server Controls, etc

 

Major Feature 1: ASPX Pages (and code behind), sub MasterPage, Private Components: css/images/javascript, ASCX controls, etc, private DAL code

Major Feature 2: ASPX Pages (and code behind), sub MasterPage, Private Components: css/images/javascript, ASCX controls, etc, private DAL code

Major Feature 3: ASPX Pages (and code behind), sub MasterPage, Private Components: css/images/javascript, ASCX controls, etc, private DAL code

 

In this case, the core application has a set of classes and resources that all major features will depend on, but the core does not depend on any of the major features.

 

It looks like is starting to sound like DNN right off the bat, but where it is different is that each "Major Feature" is like a separate mini application unto its own, rather than a discrete module meant for placing on any chosen page. The feature will have its own internal structure and relationships, yet be housed within the core application. It is meant to augment a well-structured and well-defined application, yet be separable from it to the degree that all other major features can function without it (to the degree possible). I'm not thinking so far as requiring the core to be 'intelligent' enough to detect dependencies and resolve all of them through run-time configuration, but more so the ability to independently package and deploy units of related {ASPX / ASCX / Code Behind / CSS / JS}.

 

For example, if you have a site like this: http://host/

 

Then, major feature 1 should be accessed via http://host/MajorFeature1, and any functions therein by MajoreFeature1/Function1.aspx ... etc etc

 

Physically, this is easy to implement in a single-solution / Web Application Project, by putting each feature in its own folder and following a set of conventions for naming subdirectories and file names, and for ensuring that no core parts have improper dependencies on code physically located in any of the subdirectories.

 

However, the code will all compile into one web application DLL that will need to be deployed. This is probably not a problem in most cases.

 

To get past this, you could treat each of the ASPX pages as little more than entry points and delegate all real work to controls that could be implemented in their own projects and linked to the main project. It at least keeps the functional code segregated, but the aspx pages still have to physically reside in the one big web app project.

 

The problem with this approach though is that the front-end code must be very simple and all really UI must be done purely with code behind, so far as I can tell.

 

Is there any asp.net 2.0 "standard" or de facto way to bundle up related {ASPX / ASCX / Code Behind / CSS / JS} into deployable units in this fashion, or does DNN and the like still provide the best model for going about this?

 

 

Thanks,

Josh

posted Wednesday, July 05, 2006 10:21 AM by JoshuaGough with 111 Comments




Powered by Dot Net Junkies, by Telligent Systems