Article: A Fusion of Proven Ideas: A Look Behind S#arp Architecture

Posted by Abel Avram on Mar 16, 2009

Sections

Architecture & Design,

Development

Topics

ASP.NET MVC ,

Domain-Driven Design ,

Dependency Injection ,

ASP.NET ,

.NET ,

Design ,

Design Pattern ,

Methodologies ,

Architecture ,

Programming ,

Castle ,

Frameworks ,

nHibernate ,

Patterns ,

Object Oriented Design ,

SQLite

Share |

RELATED Research

In this article Billy McCafferty presents S#arp Architecture, an ASP.NET MVC architectural framework meant to leverage current best practices in architecting ASP.NET web applications by providing a project code template which uses Domain-Driven Design techniques and has built-in support for NHibernate, Castle Windsor and SQLite.

Read: A Fusion of Proven Ideas: A Look Behind S#arp Architecture

McCafferty starts with a review of current trends in web applications architecture design: abstracted infrastructure, loose coupling, TDD and DDD. He outlines some of the lessons learned by the software community as the foundation for S#arp Architecture.

S#arp Architecture offers a project code template which uses the following frameworks and techniques:

• The Separated Interface pattern, in conjunction with the Dependency Injection pattern, for removing concrete dependencies on a data access layer from the domain and controller logic;
• The Repository pattern, for encapsulating data access concerns within discrete classes adhering to the Single Responsibility Principle;
• The Model-View-Controller pattern, realized with ASP.NET MVC, for introducing a clean separation of concerns between the view and controller logic;
• NHibernate, and its Fluent NHibernate extension, for removing the need to develop and maintain low level data storage and retrieval coding while keeping the domain in blissful ignorance of the persistence mechanism;
• Common Service Locator, with a default of Castle Windsor, to provide a loosely coupled means of interacting with the developers preferred IoC container;
• SQLite in-memory database for running behavior-driven tests versus those that emphasize integration with a persistent database;
• Visual Studio Templates and T4 Toolbox to generate project infrastructure and common CRUD scaffolding for each domain object to remove hours of redundant and tedious coding.

S#arp Architecture is currently an RC2 release targeted at ASP.NET MVC (RC2) web applications and uses NHibernate 2.0.1. A final release is to come soon.

1. Back to top

   REST and Messaging

   by Welly Tambunan

   i wonder where REST and Messaging fit in that architecture ?
   I hope someone can make a explanation ..
   thank you

   Reply

2. Back to top

   Re: REST and Messaging

   by Billy McCafferty

   Hi Welly,
   
   S#arp Architecture does not dictate the use of a particular communications approach. In other words, you can use RPC, REST (MvcContrib's for example), WCF, Web Services, etc. We're currently writing some sample pages to demonstrate how a couple of these approaches are supported.

   Reply

3. Back to top

   Re: REST and Messaging

   by Welly Tambunan

   Thanks a lot Billy for replying,
   
   Do you think it's necessary to separate command and query in that architecture ?
   
   And i hope you don't mind to give a comment about my approach here.
   In our current approach we have a different application for Services and Web. So the Core, Data and Application Service is different application from the Controllers and Web. In application layer we have WCF REST service.
   
   Web application call the rest service with jQuery. Do you think this approach is appropriate ?
   
   Your article said that we can't be an expert if we're not make a mistake. So i'm hope you understand if my approach is wrong. :)
   
   Thank you very much again Bill.

   Reply

4. Back to top

   Great article, but one quibble

   by Steve Macdonald

   First of all I really liked this article as it nicely summarizes the development landscape today.
   
   You wrote this:
   
   

   
   A major tenant of DDD is placing the behavior of the domain within the domain objects themselves. For example, instead of having a separate CustomerAccountLogic class to determine if a CustomerAccount is up to date on payments, you would simply ask the CustomerAccount itself for this information. In this way, the behavior of the domain is embedded into the model itself.

   
   
   This does not accurately reflect what Evans wrote in Domain Driven Design (the book). He specifically distinguishes between code which belongs in an object's class, and code which belongs in services (which could in fact be something like a "CustomerAccountLogic" class). Operations which affect multiple different types of objects are implemented not in the object classes themselves, but rather in these service classes (which are still part of the overall domain model). It's right in the diagram on the inside cover of the book!
   
   Also, to be really pedantic, you meant "tenet", not "tenant".

   Reply

5. Back to top

   Re: Great article, but one quibble

   by Billy McCafferty

   This is a great point to bring up Steve. In DDD, there are certainly domain services in addition to domain objects themselves. The intention behind my description was to inform readers that domain logic does not need to be completely separated from the model itself; that the model encapsulates behavior as well as data. Readers should certainly read Evans' DDD book for a more complete discussion of the implications of a DDD and where to draw the line among various DDD components. (And thanks for the spelling heads up!)

   Reply

6. Back to top

   Re: Great article, but one quibble

   by Vladimir Kelman

   I recently saw two interesting discussion on that distinction between code placed into BO (domain) classes and code placed into services. basically, that's right: if a code operates on a domain class only, it is normally placed inside, if code depends on many domain objects or an external service it is better to be placed in "business logic" service classes. Those service classes still call methods of domain objects if necessary: www.infoq.com/presentations/Making-Roles-Explic...

   Reply