Fluent.Interface


.NET open source projects embrace C#3

Every now and then you come across an open source initiative that has taken the new C# lambdas language extensions and run with them.  My two favourite at the moment are AutoFac and Moq.  And yes they are an agile developers favourite toolbox items – a DI container and Mocking framework respectively.

AutoFac enables compile-time configuration of the container, and supports scoping object creation, so that you could have a different instance per transaction, per request etc.  And to top that off it has bench marked very well especially when using the lambdas expressions.

Moq brings the fluent interface of RhinoMocks into the lambdas world, and is equally impressive.

Both libraries have good documentation and are open sourced at google code.


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.