Fluent.Interface


Billy McCaferty and his S#arp Architecture

I have been following Billy McCaferty’s Sharp Architecture project for some time now – a best practice Domain Driven Design approach to developing ASP.NET MVC web apps.  It has seen a number of iterations, the latest including the configuration with FluentNhibernate and independent ServiceLocator

In his recent article on InfoQ he discusses some of the motivations behind his TDD/DDD implementation.

What’s currently lacking, at least in the world of .NET web development, is a common architecture and foundation for application development which combines best of breed technologies and techniques, using recent technologies based on proven practices, while taking into account the availability of high quality tools developed by the open source community. S#arp Architecture is a response to this need. The open source S#arp Architecture attempts to leverage the proven practices described in this article with carefully selected tools to increase development productivity, while enabling a high level of quality and maintainability

He also makes dudious use of the T4 templating support built into VS2008 to codegen files from the Model objects through to Views and Controllers.  A great kick start for any new project – Well worth a read!

Advertisements

Oslo and new declarative language ‘D’ to be unvelied at Microsoft’s PDC 2008

The PDC postponed in 2007 will give people plenty to talk about in October.

I am particularly looking forward to the unveiling of Oslo, and getting my hands on the CTP.  I have been a Domain Driven Design advocate for a while now, and believe it is import to have a good vision for the model and how it is mapped back to implementation.  Oslo is all about modeling and is set to include:

  1. a ‘tool’ for so the BA types can visualise the problem domain
  2. a new domain specific language ‘D’ for mapping the model down to SQL.
  3. a (SQL) repository for storing the above

Microsoft has done a good job making most of .NET framework core libraries flexible and extensible, so let’s hope this will be a better offering then the Entity Framework V1, which was very limiting.  I still use NHibernate and see no reason to switch camps until they improve the design.


The right balance for Dependency Injection (DI)

I agree with some remarks in Does Dependency Injection pay off in-so-far-as developers can overdue DI.

When going putting together a best practice framework for Domain-Driven Development using NHibernate i considered how best to configure the data access. NHibernate requires some additional session factory information in addition to the database connection string. In particular this references the assembly of Objects & Hbm embedded resources that map to the database + Other name/value configuration properties.

NHibernate supports a standard way of setting this configuration information. But I needed to support multiple databases (session-factories) and wanted this configuration to sit directly within the app.config, so i went about creating my own session factory configuration handler:

<nhibernate>
  <
sessionFactories>
  <
clearFactories />
  <
sessionFactory name="SessionFactoryName" connectionStringName="ConnectionStringName">
  <
settings>
  <
clear />
  <
add name="hibernate.connection.provider"
value="NHibernate.Connection.DriverConnectionProvider"/>
  <
add name="hibernate.dialect"
value="NHibernate.Dialect.MsSql2005Dialect"/>
  <
add name="hibernate.connection.driver_class"
value="NHibernate.Driver.SqlClientDriver"/>
  <
add name="hibernate.cache.provider_class"
value="NHibernate.Cache.HashtableCacheProvider,NHibernate"/>
  <
add name="hibernate.cache.use_query_cache"
value="true"/>
  </
settings>
  <
assemblies>
  <
clear />
  <
add assembly="Domain.Common" />
  </
assemblies>
  </
sessionFactory>
  </
sessionFactories>
</
nhibernate>

I structured the code in such a way that one IDaoFactory interface that was initialized with a SessionFactory name, and it passed this name down to its respectify IDao (repository) implementations that would then load the configuration information for loading the NHibernate ISession. So in essense I was not injecting the configuration information for the ojbect, but more a pointer so it could load the information. And by seperating the IDao contract, it makes it very easy to create a Dao stub that could be used for unit testing purposes.

It is also worth noting that in the top web layer i use Castle Windsor to inject the SessionFactory name’s into the IDaoFactory objects, so as to avoid hard coding any configuration information:

<castle>
  <
components>
  <
component id="primaryDaoFactory"
type="Data.NHibernateDaoFactory, Domain.Data"
service="Domain.Interfaces.IDaoFactory, Domain.Common">
<
parameters>
<
sessionFactoryName>DCDS</sessionFactoryName>
</
parameters>
</
component>
</
components>
</
castle>

This is only introduced at the web layer, so as to avoid the dependency on the Castle framework throughout the Domain model / data libraries. So to surmise I use DI techniques in constructing objects, but minimize the injection points so as to avoid develop confusion on how/when objects are initialized.


What I’m excited about – Agile goodness of DDD/TDD/ORM

I have spent a lot of time resarching the internet (and in particular other people blogs) for information on my specific agile topics of interest:

With all that great info out there, I thought it wouldn’t hurt to have another filtered view of the world. So I will be following up with some articles on my own.

Stay tuned,

Julian.