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

by Abel Avram on Mar 16, 2009 |

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.

Related Editorial

From Killer Apps to App Killers: The Devastating Effect of Architecturally Complex Defects

Impact of Java EE Frameworks on the Structural Quality of Applications

Betfair Chooses not to Gamble with Database Performance: An AppDyanmics Case Study

Everything You Need To Know About Graph Databases – View Introductory Video

Why NoSQL - Three Trends Disrupting the Database Status Quo

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

REST and Messaging by Welly Tambunan Posted

Re: REST and Messaging by Billy McCafferty Posted

Re: REST and Messaging by Welly Tambunan Posted

Great article, but one quibble by Steve Macdonald Posted

Re: Great article, but one quibble by Billy McCafferty Posted

Re: Great article, but one quibble by Vladimir Kelman Posted

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

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.

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.

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".

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!)

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...