For the six or seven of you in the world that actually read my blog, you've noticed that i've been pretty quiet lately.  So while i'm chomping down breakfast before work, I thought I'd give you a rundown on what i've been doing lately.

I'm working on a medium size project that eventually may blow into something larger, which given the current economy would be great.  Its a front facing, product catalog, type web project, but there will soon be a comprehensive suite of admin tools, reporting, integration with other systems, etc.  So I'm trying out a new (for me) architecture for this site because I can tell it may grow into something much bigger than it already is.

So without further adieu, here is my current architecture and toolkit for this project.

1. ASP.NET MVC - Microsoft should have done this years ago.  Its a refreshing return to simplicity.  I've already written about why webforms suck.  So if you haven't checked out MVC you should.
   
2. NHibernate - Its not perfect, but if you are practicing Domain Driven Design and want to build objects that have little or no coupling to persistence logic, this is the defacto standard ORM among open sources ORMs.  I tend to shy away from the HQL as there always seems to be something missing from the language, but the criteria classes work nicely.  Of course, you can always drop back down to HQL or SQL and there's a LINQ to NHibernate in the works.  Overall, I've been pretty happy with it.
3. DDD - First off, I'm not a domain driven design expert.  But I'm trying to incorporate it as much as possible into this project.  I have domain objects for domain logic, repositories for data access (which use NHibernate) and service objects for other business logic that doesn't belong to a single domain object. 
   
4. Service Objects - While I'm on the DDD topic, i've started using "services" a lot more, which is a DDD concept.  What's an example of this?  Well, I have a UserRegistration service that takes a user object, saves it using a UserRepository, and sends an email notification using an EmailService which sends the email.  I didn't want all that logic in my controller (and you webforms people shouldn't put that stuff in the code behind!), so I refactored it into a UserRegistration service.  I also didn't want it in any domain object, because it needed to coordinate domain logic, persistence logic and the email service. I have another situation where I have a purchase inquiry where the user submits a PurchaseInquiry object that has a reference to the user, and a reference to the product they're interested in and a few other fields and saves it to the database.  But I also need to send an email and integrate into a third party CRM.  So I have a PurchaseService that saves the PurchaseInquiry (again using a "PurchaseInquiryRepository" ), sends the email using an email service and then calls into the CRM service to do the integration.  I've really been pleased with how  this "service layer" works in these complex scenarios and keeps this logic in the business layer where it belongs. I don't make service object for everything--just the places where coordination between different domain objects, services and repositories is necessary.  Also, you want to avoid the dreaded "anemic domain model" that can be a temptation when using services.  My domain objects still have a lot of behavior, but they don't cross network boundaries into outside systems (such as database, email, web services, etc.)  For these sort of thigns, I put the logic into services.  I'm not sure this is the "official" DDD way of using services, but this has been very useful to me.
   
5. JQuery - So we're not using webforms, so what do we use for controls?  Although you can use controls in MVC, part of the extra complexity in traditional webforms came from controls that contained server side and client side code (C#, Javascript, CSS) and tried to package them all together.  Styling and customization was a constant issue with many of the controls I've used and many of the useful things that controls did (such as maintaining state) no longer work in MVC's non-postback environment.  Fortunately Jquery has a suite of UI widgets, called JQuery UI and you can use these almost like server controls--you just add markup and a tiny bit of javascript to wire them up and you have tabs, menus, etc.  I'm very pleased with JQuery so far.  Ajax is especially simple.  With asp.net ajax, you have to have that stupid script manager tag, (but ONLY ONE script manager tag or you get an error), and the web.config settings, and the tags in the page to set up specifically what you are doing.  With JQuery, i write 2-3 small lines of code and they can call a controller method in MVC directly, get the results and update any part of my page. 
   
6. TDD + NUnit - I'm trying out this whole Test First methodology. I've done some TDD in the past but never went gung-ho the way I am with this project.  I have integration tests for all my data access and unit tests for domain objects, services and controllers.  Eventually I'm going to swap this out with MBUnit which is supposed to be more feature rich, but I started with NUnit because that's what I know.  So far, I can definitely see SOME of the benefits of doing Test First development.  It definitely makes refactoring easier, but I don't see a massive drop in defects.  I usually code in a somewhat loosely coupled and OO manner and don't normally have dozens or hundreds of bugs in my projects, but on the other hand the projects i've done lately have been pretty small.  Maybe as this thing grows, TDD will shine even more.  Right now its taking some getting used to, and all the "extra" code is annoying me.  I'm also using Rhino mocks for mock objects, but as this was a huge learning curve for me I'm not ready to write about it now.
   
7. General "Onion Architecture" - Much of what I've talked about above comes straight from Jeffrey Palermo's Onion Architecture and his Agile Bootcamp class.  So I'm also doing things like loose coupling between layers using Dependency Injection and Structuremap.  If you haven't looked at DI, you should.  The learning curve is very minimal and changes very little about how you write your code.  A few interfaces here, a constructor there, a tiny bit of configuration and poof!--Loosely coupled architecture!  Okay there's a little more too it than that, but TDD by far is a much larger paradigm shift.  With the DI, I've got my NHibernate mappings and repositories in a separate project that gets hooked up to my domain layer at runtime, so the implementation of the ORM and data access stuff is completely decoupled from the rest of the application.  

Read the complete post at http://dotnettricks.com/blogs/craigbowesblog/archive/2008/12/10/720.aspx