To skip to the chase... http://code.google.com/p/sharp-architecture/
It wasn't too many years ago that I used to state quietly that I was a Microsoft web developer. Inevitably, a Java developer would hear my whisper and begin laughing hysterically as I cowered away from defending Active Server Pages. Not long after, I felt a bit more confident defending Microsoft web development after the introduction of ASP.NET but have yet to this day been able to accurately describe the page life cycle or defend why the *%$@ it was ever a good idea. While the .NET language continued to progress into a world class language with generics and LINQ, I often wondered when the presentation layer would get the attention it deserved. To add insult to injury, the Rails crew was quick to join in the hysterics that the Java community had long been enjoying. To make up for the deficiencies of developing Microsoft web applications, many of us would come up with near ridiculous schemes to facilitate even a partial amount of test driven development and properly tiered layers. With ASP.NET MVC, we now easily stand shoulder to shoulder with the clean separation of concerns enjoyed by other technologies. But with any new technology, there is a dire and immediate need for communications and guidance concerning how to develop a solid, testable web application using time tested patterns for rapid development and long term maintainability. With this post, I hope to do just for ASP.NET MVC.
Pronounced "Sharp Architecture," this is a solid architectural foundation for rapidly building maintainable web applications leveraging the ASP.NET MVC framework with NHibernate 1.2 and Spring.NET 1.1.1. The primary advantage to be sought in using any architectural framework is to decrease the code one has to write while increasing the quality of the end product. A framework should enable developers to spend little time on infrastructure details while allowing them to focus their attentions on the domain and user experience. Accordingly, S#arp Architecture adheres to the following key principles:
Focused on Domain Driven Design
This architecture places emphasis on the domain as being the core element of focus. Accordingly, the domain layer has no direct dependencies on any data loading mechanisms or other resource dependent services. This facilitates a test driven approach to developing the domain without the need for external resources, such as a database, to be available during domain development. (Alternatively, some developers prefer a model driven approach to application development. A solid framework for supporting this alternative style is the ADO.NET Entity Framework.)
Loosely Coupled
All layers within S#arp Architecture depend only on the core domain layer and framework utilities. In many applications, the presentation tier depends on a service tier which depends on a domain tier which depends on a data access tier. A frequent problem with this is that every layer "up the chain" inherently depends on every tier below it. This tight coupling makes it increasingly more difficult, as development on a project proceeds, to make modifications to lower tiers without having an adverse affect on the tiers above it. Alternatively, this architecture keeps the tiers loosely coupled from each other; e.g., the controller and domain logic layers have no direct dependency on the data tier. To facilitate this, the core domin layer, in addition to defining the domain model and logic, also define service interfaces which are needed by other layers. (Examples of a "service" include a data access object, a ftp utility, or a web service.) In this way, the controller logic only has knowledge of data access interfaces, for which implementation details can be injected at runtime. This loosely coupled design further faciliates test driven development and allows dependencies to be more easily modified, if not completely replaced, with no affect on "higher" tiers.
Preconfigured Infrastructure
Developers often spend much of their time maintaining data access and other infrastructure related layers. Furthermore, infrastructure to facilitate test driven development which bypasses live data access code is often complicated and error prone to configure. By leveraging NHibernate 1.2 for data access, along with the benefits of .NET generics, it is rarely the case, using this described approach, that even a single line of code need be written to have full data access capabilities for a given domain object. Spring.NET 1.1 is then leveraged to provide dependency injection of concreate data access objects into the controllers layer. (Alternatively, the data access objects could be injected into a service layer when appropriate.) To reduce the risk of introducing bugs into XML configuration files, this framework includes a Spring.NET XML configuration generator to handle defining data access objects (DAOs), controllers, and DAO injection into controller constructors. The only time it is necessary to configure Spring.NET XML is when custom DAOs are required. Note that this is the only code generation in the entire framework. There is no bazillion lines of data access code generated upon every compilation. There are no magically created partial classes to facilitate data access. This makes for a much more understandable and maintainable application.
Open Ended Presentation
There are a plethora of great alternatives available for building the presentation layer of an application. Consequently, S#arp Architecture mandates few, if any, constraints on how the presentation layer should be designed and developed. In fact, the only constraint is that ASP.NET MVC be leveraged; other than that, any presentation option is available for use. To illustrate, this framework shows no preferences towards any particular presentation solution such as jQuery, Yahoo UI widgets, or the Microsoft AJAX utilities. As long as your preferred mechanism works with MVC, this framework will accommodate it.
To better facilitate community involvement, to provide releases for later versions of ASP.NET MVC and other framework dependencies, and to manage documentation (with a comprehensive walk through lab), S#arp Architecture is being managed at http://code.google.com/p/sharp-architecture/. The corresponding discussion group may be found at http://groups.google.com/group/sharp-architecture.
I sincerely hope that this architecture will serve as a key element in enabling you to create high quality applications which both you and your clients can take pride in. This work reflects the knowledge of industry experts, the feedback garnered from past experiences, and the help of many people who have lent a hand or provided guidance and/or feedback when needed. Particularly, I'd like to thank Damon Carr, Ben Scheirman, Alan Northam, Mark Pollack and Erich Eichinger of the Spring.NET team, Wayde Gilliam and the hundreds of developers who helped me hone my ideas by providing great feedback over the past couple of years. A special thanks also goes to Roy Bradley who made it possible for me to spend as much time as I did on this effort.
Some useful essential background material for this architecture may be found at http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx. Although there are major changes in the infrastructure of the new architecture, the overall structure is similar to that presented in this previous article. So it's a great starting point for getting up to speed with the knowledge areas included.
The overall goal of this architecture is to allow developers to worry less about application "plumbing" and to spend most of their time on adding value for the client by focusing on the business logic and developing a rich user experience. Enjoy and keep the feedback coming!
Billy McCafferty