I recently stumbled across Billy McCafferty's new open source project, S#arp Architecture, and I must say that I am quite impressed. From the S#arp Architecture project description:
Pronounced
"Sharp Architecture," this is a solid architectural foundation for
rapidly building maintainable web applications leveraging the ASP.NET
MVC framework with NHibernate and Spring.NET. 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
Loosely Coupled
Preconfigured Infrastructure
Open Ended Presentation
The
overall goal of this 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.
I had previously read Billy's excellent post on best practices using NHibernate (which appears to have inspired much of the code in S#arp Architecture) and had been meaning to play around with it. I had also been meaning to give the new ASP.NET MVC framework a spin. So naturally I was pretty excited to see both in play in the S#arp Architecture project. Installation was a breeze. Aside from making a minor modification in my Global.asax.cs file (changed the route from {controller}.mvc to {controller}) and editing my connection string, all I had to do was hit F5 in Visual Studio 2008 and everything fired up ready to go. I read through the documentation and looked through the source and there is a lot of good stuff here. Test driven development, object relational mapping, dependency injection / inversion of control, separation of concerns, and model-view-controller all rolled into one well-documented and commented package. The project looks like a "best of" compilation of all the hot topics in the .NET world.
What I really like about the S#arp Architecture design (and what differentiates it from most of the other ASP.NET MVC projects out there) is its focus on domain driven design (DDD). Nearly all of the ASP.NET MVC examples out there that I have seen use LINQ to SQL, which (as far as I can tell) just doesn't work well in a disconnected n-tier architecture (at least not without having to leap through some hoops). But more importantly, LINQ to SQL almost necessitates the use of an active record design pattern, or at least a design pattern where the database has a direct influence over the construction of your domain objects. I know that there are many developers out there who love active record as evidenced by the success of Ruby on Rails, Subsonic (which I am also a big fan of for smaller-scale projects), and Castle Project's ActiveRecord. However, I've found that designing the classes first without regard for how they will be persisted to the database leads to much cleaner code.
For example, assume you have a "Customers" table in your database that contains columns for your customer's billing address information (e.g. street address, city, state, zip, etc.). Using an active record approach, you would have a corresponding Customers class in your domain that contained properties for each of the billing address columns. Now, say you wanted to add shipping address information to that same "Customers " table. You now have additional properties for each of those shipping address columns in your Customers class, bloating the class with duplicate fields (e.g. ShippingAddressCity and BillingAddressCity). In addition to which, if you suddenly decide that your addresses need to contain county information, you have another two properties in your Customers class: ShippingAddressCounty and BillingAddressCounty. Whereas with a domain driven design approach, you would create an Address class first to represent any generic address and have the Customer class contain two Address properties, one for the shipping address and one for the billing address. Any refactoring of the Address class would take place in one location only and the Customer class now isn't bloated with tons of address specific properties. The database structure remains unchanged from the active record approach, but the domain ends up much cleaner with the domain driven design approach (not to mention that it's a lot easier to differentiate between where the ORM starts and where the business logic ends this way).
What's also nice to see here is a project aimed at a more realistic project. Aside from Rob Conery's MVC Storefront series (which I am also following), I haven't seen much educational material for ASP.NET MVC geared towards those of us who already understand the MVC concept and how routing is handled in ASP.NET MVC. It's nice to see the advantages this framework provides, as well as its disadvantages.
Speaking of which, I must admit that going MVC is a major shift from web forms. There have been more than a few times where I've felt a bit lost and yearning for the ease of use of web forms. Viewstate, server side events, ASP.NET validators, gridviews, and login controls are all gone in favor of pure HTML (I'd include ASP.NET AJAX in here, but honestly I don't miss it at all). And while this affords me incredible control over my application's HTML (no more ugly ids and encoded viewstates, yay!), it does require that I pay a bit more attention while I'm coding away.
Overall, I'm very excited about the S#arp Architecture project and I expect to be tinkering around with it for some time to come. I've got a website I need to throw together for my wife's new business anyhow, and it seems like a good opportunity to improve my coding skills. I'll keep posting on what I find as I trudge along.
Enjoyed this post? Share it with others!