Status Quo

In 2007 there was a movement in the .NET community dubbed “ALT.NET”.  A community was formed by individuals who believed there to be a “better” way from the tooling, frameworks, practices and principles provided by Microsoft.  The initial release of Linq to Entities (Entity Framework) was really a starting point for discussion since it did not support POCO’s and was not persistence ignorant.

ALT.NET was about challenging the status quo.  Although some might not be familiar with with the ALT.NET movement, you can thank it for helping the common practice of: Inversion of Control (Dependency Injection), Persistence Ignorant ORM’s, and SOLID principles.

So what happened to the community?  Was it a failure since it is no longer as active?  Or was it a success because many of the alternatives are now the “norm”?  I believe it to be both.

We need to continue challenging the status quo.  Individually and as a community.  Innovation and process improvement can only come from alternative thinking.  Have pride for the software you develop (Manifesto for Software Craftsmanship) and improve upon the existing practices.

CQRS: Read Model

Keep it simple.  There isn’t much of a need to go out of your way adding extra layers of abstraction.  Any data access framework or ORM you might be using will already be creating a good enough level of abstraction.  With linq (IQueryable) being implemented in NHibernate, Entity Framework, or Linq to SQL, ORM du jour, you already have your a level of abstraction to your data source.

Need to query your read model from the client? Single page application maybe?  Ok… you need one more layer.  OData to the rescue.  WCF Data Services provides an incredibly easy implementation with Entity Framework.  ASP.NET Web API does have an OData implementation but has limitations.

Keep it simple:

  • Data Source
  • Data Access Layer (ORM)
  • OData Layer – only if needed if client is making the query
  • Client