Why is Event Driven Architecture good?

Event driven architecture is extremely extensible. In my mind, it the perfect solution to address the Open Closed Principal and enable Single Responsibility in code.

Consider a system that processes orders. There is a method called SubmitOrder(order) on an OrderController. It just validates and saves the new order to the database today.

In a following story, the product owner says “I need the system to send an email to the customer when the order is submitted”. No problem, inject the MailService into the OrderController, send the mail in the SubmitOrder(order) method. great.

The next story the product owner says “I need you to deduct the ordered quantities from the OnHand inventory”. Check, so we inject in the inventory service into our OrderController, and we call it from the SubmitOrder(order) method.

More stories…. the product owner says “We need to send a message to the warehouse fulfillment system to let them know a new order has been submitted”

Ugh, another service, another method. The tests for SubmitOrder become out of control. Even when extracting methods and encapsulating more logic into services, there is still violation of SRP & OCP. Not to mention there could be performance degradation from performing all of these tasks synchronously while the user waits.

Its not the job of SubmitOrder to do all of this, there has to be a better way.

Publishing an Event Example

What if I “tell” the system that an event had occurred, and anyone interested could take action? (like an old school observer right?) In the following code sample I am going to inject in an ‘EventPublisher’ into my OrderController, then use that object to notify the rest of the system by publishing an event using this line:

_eventPublisher.Publish(new OrderSubmittedEvent{OrderId = order.Id});

The OrderController

public class OrderController : Controller

{

   private readonly IRepository<Order> _orderRepository;

   private readonly IEventPublisher _eventPublisher;

   public OrderController(IRepository<Order> orderRepository, 

                          IEventPublisher eventPublisher)

   {

       _orderRepository = orderRepository;

       _eventPublisher = eventPublisher;

   }

   public ActionResult SubmitOrder(OrderViewModel viewModel)

   {

       try

       {

           if (ModelState.IsValid)

           {

               var order = MapOrder(viewModel);

               _orderRepository.Add(order);

               _orderRepository.SaveChanges();

               _eventPublisher.Publish(new OrderSubmittedEvent{OrderId = order.Id});

               //Display success message

               //ViewInfo.AddSuccessMessage(Language.SubmitOrderSuccess);

           }

       }

       catch

       {

           ModelState.AddModelError("__Form", Language.SubmitOrderError);

       }

       return View(viewModel);

   }

   //other

}

Now, using this simple Consumer (Handler) interface:

public interface IConsumer<T>

{

    void Handle(T eventMessage);

}

I can independently implement each of the system requirements, as needed:

public class EmailOrderConfirmation : IConsumer<OrderSubmittedEvent>

{

   public void Handle(OrderSubmittedEvent eventMessage)

   {

      //send email

   }

}

public class NotifyWarehouse : IConsumer<OrderSubmittedEvent>

{

   public void Handle(OrderSubmittedEvent eventMessage)

   {

       //notify warehouse

   }

}

public class DeductOnHandInventory : IConsumer<OrderSubmittedEvent>

{

   public void Handle(OrderSubmittedEvent eventMessage)

   {

       //deduct inventory

   }

}

One of my favorite parts about this code: the container is building up all of these event consumers, which makes it is easy to satisfy all of the dependencies using constructor injection. This makes testing each of these handlers a breeze, and everything follows the same patterns and conventions keeping the code base understandable and clean. (Services, Controllers, Consumers all work the same)

Just plug in the dependencies in the EmailOrderConfirmation consumer ctor* like so:

public class EmailOrderConfirmation : IConsumer<OrderSubmittedEvent>

{

   private readonly IRepository<Order> _orderRepository;

   private readonly ISmtpService _smtpService;

   private readonly ILogger _logger;

   public EmailOrderConfirmation(IRepository<Order> orderRepository, 

                                 ISmtpService smtpService,

                                 ILogger logger)

   {

       _orderRepository = orderRepository;

       _smtpService = smtpService;

       _logger = logger;

   }

   public void Handle(OrderSubmittedEvent eventMessage)

   {

       var order = _orderRepository.Single(x => x.Id == eventMessage.OrderId);

       var message = new SmtpMessage();

       //get customer info from order  & populate message

       _smtpService.SendMessage(message);

   }

}

* Note that you could also inject the IEventPublisher into a Consumer and publish more events.

How Does it Work?

Under the hood the IoC container is doing most of the work. It keeps track of the event subscriptions and also provides the consumer instantiation.

Event Subscriptions

Here is how the event subscriptions are added to the container. In this example I use an interface so that I can enable dependency injection into components, and then mock the GetSubscriptions<T> dependency for easy testing. I also use a static method for adding subscriptions since the registration process operation usually happens at bootstrapping time, which is generally all static. The IoC.Container here is thread safe.

public interface ISubscriptionService

{

   IEnumerable<IConsumer<T>> GetSubscriptions<T>();

}

public class EventSubscriptions : ISubscriptionService

{

   public static void Add<T>()

   {

       var consumerType = typeof(T);

       consumerType.GetInterfaces()

                   .Where(x => x.IsGenericType)

                   .Where(x => x.GetGenericTypeDefinition() == typeof(IConsumer<>))

                   .ToList()

                   .ForEach(x => IoC.Container.RegisterType(x, 

                                                            consumerType, 

                                                            consumerType.FullName));

   }

   public IEnumerable<IConsumer<T>> GetSubscriptions<T>()

   {

       var consumers =  IoC.Container.ResolveAll(typeof(IConsumer<T>));

       return consumers.Cast<IConsumer<T>>();

   }

}

Event Publishing

Now that the subscriptions are setup, the publisher can read those subscriptions, get the consumers from the container, and pass the event message instance to each of them. Again I am using an Interface so I can enable dependency injection (and mocking capabilities) for the components which need to do publishing (controllers, services)

public interface IEventPublisher

{

   void Publish<T>(T eventMessage);

}

public class EventPublisher : IEventPublisher

{

   private readonly ISubscriptionService _subscriptionService;

   public EventPublisher(ISubscriptionService subscriptionService)

   {

       _subscriptionService = subscriptionService;

   }

   public void Publish<T>(T eventMessage)

   {

       var subscriptions = _subscriptionService.GetSubscriptions<T>();

       subscriptions.ToList().ForEach(x => PublishToConsumer(x, eventMessage));

   }

   private static void PublishToConsumer<T>(IConsumer<T> x, T eventMessage)

   {

       try

       {

           x.Handle(eventMessage);

       }

       catch(Exception e)

       {

           //log and handle internally

       }

       finally

       {

           var instance = x as IDisposable;

           if (instance != null)

           {

               instance.Dispose();

           }

       }

   }

}

- Keep in mind in this example is all running on the same thread, therefore even though semantically we are handling events as if they are asynchronous, it is a blocking operation

Additional Benefits of this Architecture

- Events are in messages, which can be serialized and processed on different threads, or even different nodes in a cluster. In a web environment, this might mean offloading the workload out of your IIS processes freeing web-server threads for performance & scalability (see Service Bus section)

- Get multicast delegate observer like functionality without having to deal with static events, event registration & deregistration (the whole += –= biz)

- Each event handler has its own class, each having 1 responsibility

- Very extensible, very maintainable (wait, I said that already?)

This is not a Service Bus

This code above could work great in a simple MVC.NET application for implementing clean separation and structuring your code base into events. Though it gets a lot of influence from the OSS services busses, it is greatly simplified and merely demonstrates a simple concept of publishing & consuming domain events using an IoC container.

A service bus does quite a bit more than just publishing local messages on single thread. If you find yourself enjoying this posts and want to take it to the next level, check out MassTransit (Chris Patterson & Dru Sellers) & nServiceBus (Udi Dahan). I would also recommend the EAI patterns books by Gregor Hohpe and recognize the reference patterns. (one of these days Ill make it through it instead of using it for reference!)

Some additional concepts and common patterns you might find:

• Publish-Subscribe
• Request-Response
• Sagas (Workflow)
• Correlation
• Competing Consumers
• Distributed Load (processing across many nodes in cluster)
• Transport (Http, MSMQ, ActiveMq, WCF TCP)
• Serialization (Binary, XML, JSON)
• Threadpooling

The Specification

Normally I don’t make a habit of testing the container, but in this case its so close to the container I feel its appropriate vs mocking out the subscriptions. Plus since this is a blog post demonstrating advanced IOC usage, I want explicitly show all of the dependencies required at bootstrap time.

Please note the LoggerSpy for assertions. In this spec we are really only concerned whether or not they get called. Because of the nature of eventing, using a Test Spy is really the only good way I have found to assert whether or not your handlers get invoked. (If your processing on multiple threads you will have to make sure they are all done before you check assertions, perhaps a future blog post)

[TestFixture]

public class When_An_Order_Is_Submitted : Specification_Context

{

   private LoggerSpy _loggerSpy;

   private Mock<IRepository<Order>> _orderRepositoryMock;

   readonly IUnityContainer _container = IoC.Container;

   protected override void Context()

   {

       //setup EF repository mock

       _orderRepositoryMock = new Mock<IRepository<Order>>();

       //logger spy to capture handler messages

       _loggerSpy = new LoggerSpy();

       //register with container

       _container.RegisterInstance<ILogger>(_loggerSpy);

       _container.RegisterInstance(_orderRepositoryMock.Object);

       _container.RegisterType<IEventPublisher, EventPublisher>();

       _container.RegisterType<ISubscriptionService, EventSubscriptions>();

       _container.RegisterType<OrderController>();

       //add event subscriptions

       EventSubscriptions.Add<EmailOrderConfirmation>();

       EventSubscriptions.Add<NotifyWarehouse>();

       EventSubscriptions.Add<DeductOnHandInventory>();

   }

   protected override void Because()

   {

       _container.Resolve<OrderController>().SubmitOrder(new OrderViewModel());

   }

   [Test]

   public void Order_Should_Be_Persisted()

   {

       _orderRepositoryMock.Verify(x => x.Add(It.IsAny<Order>()));

       _orderRepositoryMock.Verify(x => x.SaveChanges());

   }

   [Test]

   public void Email_Notification_Should_Be_Sent_To_Customer()

   {

       _loggerSpy.LoggedMessages.ShouldContain(Language.OrderConfirmationEmailSuccess);

   }

   [Test]

   public void On_Hand_Inventory_Should_Be_Reduced()

   {

       _loggerSpy.LoggedMessages.ShouldContain(Language.DeductOnHandInventorySuccess);

   }

   [Test]

   public void Warehouse_Should_Be_Notified()

   {

       _loggerSpy.LoggedMessages.ShouldContain(Language.NotifyWarehouseSuccess);

   }

}

This is something I have been using in my codebase to handle domain events, as well as a publish/subscribe mechanism for WCF message handling. I learned about this Handler<T>(or Consumer<T>) approach from the MassTransit codebase. For those that don’t know about MassTransit, it is lean service bus implementation for building loosely coupled applications using the .NET framework. I highly recommend checking it out.

Though I am a big fan of StructureMap, I have also use the Unity dependency injection container to resolve my handlers/consumers.

The Open Generic Handler

As Jimmy described in his post, there is an generic interface describing a contract

public interface IHandler<TEvent> 

{

    void Handle(TEvent args);

}

The Implementation

The interface is implemented specifying the type (the Domain Event) for the interface contract

public class OrderCanceledEvent

    : IHandler<OrderCanceledMessage>

{

    public void Handle(OrderCanceledMessage args)

    {

        // send an email or something

    }

}

Resolving the Handler

When a given domain event occurs, the handler(s) is resolved for the given event, the “T”, or OrderCancelledMessage.

var handler = container.Resolve<IHandler<OrderCanceledMessage>>();

Configuring Unity

There are a few ways to do this with Unity. I will show how to do it using a Unity Extension. Since this is fairly trivial, you could easily do it with a regular old Extension method, which would result in less setup code.

Basically the extension going to do is drill into the impl type and extract the interface that matches the passed in generic, and register it in the container.

The Unity Extension

public class OpenGenericExtension : UnityContainerExtension, IOpenGenericExtension

{

    protected override void Initialize()

    {

    }

    public void RegisterClosedImpl<T>(Type openGenericInterface)

    {

        var closedType = typeof(T);

        closedType.GetInterfaces()

                  .Where(x => x.IsGenericType)

                  .Where(x => x.GetGenericTypeDefinition() == openGenericInterface)

                  .ToList()

                  .ForEach(x => Container.RegisterType(x, closedType));

    }

}

public interface IOpenGenericExtension : IUnityContainerExtensionConfigurator

{

    void RegisterClosedImpl<T>(Type openInterface);

}

The Test

Make it go.

[Test]

public void should_connect_types()

{

    var container = new UnityContainer();

    container.AddNewExtension<OpenGenericExtension>()

             .Configure<IOpenGenericExtension>()

             .RegisterClosedImpl<OrderCanceledEvent>(typeof(IHandler<>));

    var handler = container.Resolve<IHandler<OrderCanceledMessage>>();

    Assert.AreEqual(handler.GetType(), typeof(OrderCanceledEvent));

}

A Typical DI Example

Though its pretty typical, I thought it would be good to show an example of how I expect to work with a Repository in my application. The “End Result” if you will.

The following is how one of my MVC.NET controllers might look (same for domain services, WCF services etc). Dependencies are satisfied via constructor injection when the controller or service is built up by the infrastructure (ControllerFactory or perhaps WCF IInstanceProvider).

public class RosterController

{

   private readonly IRepository<Team> _teamRepository;

   public RosterController(IRepository<Team> teamRepository)

   {

       _teamRepository = teamRepository;

   }

   public void AddNewPlayer(long teamId, string playerName, string position)

   {

       var team = _teamRepository.First(x => x.ID == teamId);

       team.Players.Add(new Player{ Name = playerName, Position = position });

   }

}

In order to “wire up” the above example, there is quite a bit that has to happen.

The Unity Extension

Unity provides extension points, called UnityContainerExtension’s which are a perfect place to handle IOC initialization for a given component. For those familiar with Castle Windsor facilities, its kind of like that (or StructureMap registries).

The EFRepositoryExtension (could probably use a better name?) handles:

• Creating the ContextBuilder and registering it with the Container
• Registering the Generic Repository<T> and UnitOfWork
• Context Lifetime
• Entity Configuration & EntitySet Registration
• Context BuildUp

The end result is nice clean extension I can register in my BootStrapper like so:

var container = IoC.Container; //some static, thread safe container class

container.AddNewExtension<EFRepositoryExtension>();

container.Configure<IEFRepositoryExtension>()

         .WithConnection(cnxString)

         .WithContextLifetime(new HttpContextLifetimeManager<IObjectContext>())

         .ConfigureEntity(new TeamConfiguration())

         .ConfigureEntity(new PlayerConfiguration());

A pretty nice API to work with if I get to say so

Fluent Interface

public interface IEFRepositoryExtension : IUnityContainerExtensionConfigurator

{

    IEFRepositoryExtension WithConnection(string connectionString);

    IEFRepositoryExtension WithContextLifetime(LifetimeManager lifetimeManager);

    IEFRepositoryExtension ConfigureEntity<T>(EntityConfiguration<T> config);

    IEFRepositoryExtension ConfigureEntity<T>(EntityConfiguration<T> config, string setName);

}

Extension Implementation

public class EFRepositoryExtension : UnityContainerExtension, IEFRepositoryExtension

{

  private ContextBuilder<ObjectContext> _builder;

  private SqlConnection _connection;

  protected override void Initialize()

  {

      _builder = new ContextBuilder<ObjectContext>();

      //register the builder instance as a singleton, this will hold all of our 

      //mapping information for the duration of our application as it creates 

      //new data contexts

      Container.RegisterInstance("builder", _builder, 

                                 new ContainerControlledLifetimeManager());

      //Register Repo & UOW. Those these are transient instances, they both take

      //a ctor dependency on the ObjectContext which has its lifetime controlled

      //by the Extension. E.g., for an Http current request, all repository and

      //UOW will use the same context/transaction

      Container.RegisterType(typeof(IRepository<>), typeof(Repository<>));

      Container.RegisterType<IUnitOfWork, UnitOfWork>();

  }

  public IEFRepositoryExtension WithConnection(string connectionString)

  {

      _connection = new SqlConnection(connectionString);

      return this;

  }

  public IEFRepositoryExtension ConfigureEntity<T>(EntityConfiguration<T> config)

  {

      //simple pluralization of the entity set

      ConfigureEntity(config, typeof(T).Name+"s");

      return this;

  }

  public IEFRepositoryExtension ConfigureEntity<T>(EntityConfiguration<T> config, 

                                                   string setName)

  {

      //add the configuration

      _builder.Configurations.Add(config);

      //register the set metadata

      _builder.RegisterSet<T>(setName);

      return this;

  }

  public IEFRepositoryExtension WithContextLifetime(LifetimeManager lifetimeManager)

  {

      Container.AddNewExtension<StaticFactoryExtension>();

      Container.Configure<IStaticFactoryConfiguration>()

               .RegisterFactory<IObjectContext>(x => 

                   ContextResolver(x, lifetimeManager, _connection));

      return this;

  }

  //factory func to build context with given lifetime & connection

  static readonly Func<IUnityContainer, LifetimeManager, SqlConnection, object> 

      ContextResolver = (c, l, s) =>

      {

          var context = l.GetValue();

          if (context == null)

          {

              var builder = c.Resolve<ContextBuilder<ObjectContext>>("builder");

              var newContext = builder.Create(s);

              context = new ObjectContextAdapter(newContext);

              l.SetValue(context);

          }

          return context;

      };

}

The Test

Doing simple service location & using TestLifetime, my prototype (not really a “test” I suppose)looks like:

var cnxString = ConfigurationManager.ConnectionStrings["Test"].ConnectionString;

var container = IoC.Container; //some static, thread safe container class

container.AddNewExtension<EFRepositoryExtension>();

container.Configure<IEFRepositoryExtension>()

    .WithConnection(cnxString)

    .WithContextLifetime(new TestLifetimeManager<IObjectContext>())

    .ConfigureEntity(new TeamConfiguration())

    .ConfigureEntity(new PlayerConfiguration());

container.RegisterType<RosterController>();

var rosterController = container.Resolve<RosterController>();

rosterController.AddNewPlayer(3, "Austin Collie", "");

container.Resolve<IUnitOfWork>().Commit();

Thoughts and feedback are welcome.

A popular pattern for ORM data access is the Repository pattern. Implementing a generic repository in EF4 gets much easier with ObjectSet<T>. One might argue that it is, in a sense, a Repository.

What I would like to do is “Adapt” this interface to my own generic Repository. This will let me customize the interface to my own specifications and remove the dependency in my domain services on ObjectSet<T>.

Here is a great article based on the last CTP that does a nice job of laying out a Repository<T> strategy with a UnitOfWork, and here is another using nHibernate (see also UnitOfWork examples). If you are not familiar with the Generic Repository pattern and UnitOfWork, you should take a quick second and skim these before you continue. I want to take this implementation and try and change just a few things about it.

• Static Unit of Work reference: First, I want to remove the Repository static reference to the UnitOfWork, which is how the Repository in the examples are resolving the ObjectContext/Session. Aside from not being a fan of static classes, I think it is the application Container’s responsibility to manage dependency resolution. Plus, I don’t really know that I want my Repository to have any reference to the UnitOfWork. I want the UnitOfWork to span across multiple repositories within a given transaction.
• Object Lifetime: I would like to have more granular control over the UnitOfWork and ObjectContext lifetime. In the authors example, the UnitOfWork is managing the lifetime strategy, which is something the Container is perfect at handling. I will leave the UOW to transaction management only.
• Constructor Injection: I think since the Repository has a hard dependency on the ObjectContext, that it would make the most sense to have the ObjectContext injected into Repository ctor.
• Concrete ObjectContext reference: Since I will now be passing the ObjectContext into the ctor, I feel better if this was an interface. Not that I foresee a tremendous amount of testable value here, but I still don’t like taking a ctor dependency on a framework object if I can avoid it. Plus, this is prototype code, so why not?

Repository Interface

You will notice the interface remains unchanged from the first referenced article (Update: changed Func<T, bool> to Expression<Func<T, bool>> so that expressions can be evaluated correctly by ObjectQuery)

public interface IRepository<T> where T : class

{

    IQueryable<T> AsQueryable();

    IEnumerable<T> GetAll();

    IEnumerable<T> Find(Expression<Func<T, bool>> where);

    T Single(Expression<Func<T, bool>> where);

    T First(Expression<Func<T, bool>> where);

    void Delete(T entity);

    void Add(T entity);

    void Attach(T entity);

Generic Repository Implementation

As I described in the bullets above, my implementation does in fact take the IObjectContext as a ctor argument. Also, notice that I do not have any static references.

public class Repository<T> : IRepository<T> where T : class

{

   IObjectSet<T> _objectSet;

   public Repository(IObjectContext objectContext)

   {

       _objectSet = objectContext.CreateObjectSet<T>();

   }

   public IQueryable<T> AsQueryable()

   {

       return _objectSet;

   }

   public IEnumerable<T> GetAll()

   {

       return _objectSet.ToList();

   }

   public IEnumerable<T> Find(Expression<Func<T, bool>> where)

   {

       return _objectSet.Where(where);

   }

   public T Single(Expression<Func<T, bool>> where)

   {

       return _objectSet.Single(where);

   }

   public T First(Expression<Func<T, bool>> where)

   {

       return _objectSet.First(where);

   }

   public void Delete(T entity)

   {

       _objectSet.DeleteObject(entity);

   }

   public void Add(T entity)

   {

       _objectSet.AddObject(entity);

   }

   public void Attach(T entity)

   {

       _objectSet.Attach(entity);

   }

Unit of Work

Just like EF4 ObjectSet does a lot out of box for our Repository, the EF ObjectContext really does a lot of the work for us in regards to managing the UnitOfWork. The Object context is already capable of handling a transaction across many operations over different types. So, again, we are going to just add a little wrapper around the context and call it a UnitOfWork. This will give me a nice hook where my infrastructure can snag a reference to the ObjectContext and Commit the transaction changes, for example, at the end of a WCF, Web or DataService request.

interface IUnitOfWork

{

    void Commit();

}

public class UnitOfWork: IUnitOfWork, IDisposable

{

    private readonly IObjectContext _objectContext;

    public UnitOfWork(IObjectContext objectContext)

    {

        _objectContext = objectContext;

    }

    public void Dispose()

    {

        if (_objectContext != null)

        {

            _objectContext.Dispose();

        }

        GC.SuppressFinalize(this);

    }

    public void Commit()

    {

        _objectContext.SaveChanges();

    }

}

The Object Context Adapter

Just some Adapter 101 code here to abstract away the Concrete Context

public interface IObjectContext : IDisposable

{

    IObjectSet<T> CreateObjectSet<T>() where T : class;

    void SaveChanges();

}

public class ObjectContextAdapter : IObjectContext

{

    readonly ObjectContext _context;

    public ObjectContextAdapter(ObjectContext context)

    {

        _context = context;

    }

    public void Dispose()

    {

        _context.Dispose();

    }

    public IObjectSet<T> CreateObjectSet<T>() where T : class

    {

        return _context.CreateObjectSet<T>();

    }

    public void SaveChanges()

    {

        _context.SaveChanges();

    }

}

Using the Repository

Without out my application Container, here is how I would code up the new abstractions:

//...

// a bunch of ugly set up code here, see previous post

//...

var context = builder.Create(connection);

var contextAdapter = new ObjectContextAdapter(context);

var unitOfWork = new UnitOfWork(contextAdapter);

var teamRepository = new Repository<Team>(contextAdapter);

var newTeam = new Team { Name = "Da Bears" };

teamRepository.Add(newTeam);

unitOfWork.Commit();

var team = teamRepository.First(x => x.Name == "Da Bears");

Console.WriteLine(team.Name);

context.Dispose();

Admittedly, this is not very pretty and is still way more than I want to deal with on regular basis. In my next post I will demonstrate how I will tie all this together, EF Configuration, Repository and UnitOfWork using a Unity Extension.

Please keep in mind this is prototype, untested code on a CTP release. Code at your own risk!

In this post I want to take a look a simple mapping scenario, and how that looks using the new ‘Code Only’ API. By using the code only API I can have complete control over my entities, giving me the most flexibility in my mapping strategies, better testability and extensibility, and ultimately greater maintainability. No generated code. No XML files. Sweet

Since I am a sports fanatic I am going to use one of my favorite models, the sports team. (Hey, I could be using Orders!)

The Database Table

I will start by defining a simple table with 2 columns, Name and ID:

CREATE TABLE [dbo].[Teams](

    [ID] [bigint] IDENTITY(1,1) NOT NULL,

    [Name] [nvarchar](50) NULL,

 CONSTRAINT [PK_Team] PRIMARY KEY CLUSTERED ([Id] ASC)

) ON [PRIMARY]

GO

The Entity

When creating an Entity the default convention is that the Entity property names should match the database column names exactly. I will create a Team entity which does that like so:

public class Team

{

    public long Id { get; set; }

    public string Name { get; set; }

}

The Mapping

Mapping the Entity to the table is very easy. To do so, implement a Generic class EntityConfiguration<T> and setup the map in the ctor. For the Team entity, that will look like this:

public class TeamConfiguration : EntityConfiguration<Team>

{

    public TeamConfiguration()

    {

        Property(c => c.Id).IsIdentity();

        Property(c => c.Name).HasMaxLength(50).IsRequired();

    }

}

The Infrastructure

Now that I have the entity and table mapped together, I need to provide the EF infrastructure with the configuration, and then I can begin working with the Entity(ies).

Connection

A simple connection string. I felt this was worth pointing out for those that have used EF3.5. Note that this is just a simple DB connection, and does not contain the metadata parts.

<configuration>

  <connectionStrings>

    <add name="Test" connectionString="Data Source=.;Initial Catalog=Test;

        Integrated Security=True;MultipleActiveResultSets=True"/>

  </connectionStrings>

</configuration>

The Object Context

If you look at the CTP walkthrough you will notice the sample includes a class called BloggingModel which derives from ObjectContext. BloggingModel has properties for each ObjectSet<T>. I believe this is done so that the ContextBuilder can infer the EntitySets and build the correct metadata. To me this is an unnecessary class that I would rather not maintain. Instead, before I create the context,  I will handle the metadata registration by calling “builder.RegisterSet<T>("SetName");” (For now… see future post).  If I did not do this, the context would use the default naming convention for our EntitySet, and would expect a table named “TeamSet”.

//create builder

var builder = new ContextBuilder<ObjectContext>();

//add our Team set configuration

builder.Configurations.Add(new TeamConfiguration());

//keep in mind this call is to avoid custom object context

builder.RegisterSet<Team>("Teams");

//setup connection

var cnxString = ConfigurationManager.ConnectionStrings["Test"].ConnectionString;

var connection = new SqlConnection(cnxString);

//create the context

var context = builder.Create(connection);

//now we have a good context, and can go to work

var teams = context.CreateObjectSet<Team>();

teams.AddObject(new Team { Name = "New Orleans Saints" });

context.SaveChanges();

context.Dispose();

Aside from some of the context setup code, it’s fairly straight forward. Simple data access with a POCO entity.  check.

Extending the Entity with a One-to-Many Relationship

Now that I have the basic mapping down, I want to go one step further and add a one-to-many relationship. What’s a team without players?

Player Table

CREATE TABLE [dbo].[Players](

    [ID] [bigint] IDENTITY(1,1) NOT NULL,

    [Team_ID] [bigint] NOT NULL,

    [Name] [nvarchar](50) NOT NULL,

    [Position] [nvarchar](50) NOT NULL,

 CONSTRAINT [PK_Players] PRIMARY KEY CLUSTERED ([ID] ASC)

) 

GO

ALTER TABLE [dbo].[Players]  WITH CHECK ADD  CONSTRAINT [FK_Players_Teams] FOREIGN KEY([Team_ID])

REFERENCES [dbo].[Teams] ([ID])

GO

ALTER TABLE [dbo].[Players] CHECK CONSTRAINT [FK_Players_Teams]

GO

Entities and Mappings

I have added an ICollection to Team for the Players, and each Player has a 1-1 Team property. Mapping the collection is straight forward by using the “Relationship()”  method which takes my expression for the properties I am mapping too.

public class Team

{

    public Team()

    {

        Players = new Collection<Player>();

    }

    public long ID { get; set; }

    public string Name { get; set; }

    public ICollection<Player> Players { get; set; }

}

public class Player

{

    public long ID { get; set; }

    public string Name { get; set; }

    public string Position { get; set; }

    public Team Team { get; set; }

}

public class TeamConfiguration : EntityConfiguration<Team>

{

    public TeamConfiguration()

    {

        Property(c => c.ID).IsIdentity();

        Property(c => c.Name).HasMaxLength(50).IsRequired();

        // 1 to * relationships     

        Relationship(c => c.Players).IsOptional();

        //set up inverse

        Relationship(c => c.Players).FromProperty(x => x.Team);

    }

}

public class PlayerConfiguration : EntityConfiguration<Player>

{

    public PlayerConfiguration()

    {

        Property(c => c.ID).IsIdentity();

        Property(c => c.Name).HasMaxLength(50).IsRequired();

        Property(c => c.Position).HasMaxLength(50).IsRequired();

        Relationship(c => c.Team).IsRequired();

        Relationship(c => c.Team).FromProperty(x => x.Players); 

    }

}

var teams = context.CreateObjectSet<Team>();

var team = new Team { Name = "Indianapolis Colts" };

var player1 = new Player { Name = "Peyton Manning", Position = "QB"};

var player2 = new Player { Name = "Reggie Wayne", Position = "WR" };

team.Players.Add(player1);

team.Players.Add(player2);

teams.AddObject(team);

context.SaveChanges();

//create new player set to show we are pulling back from db

var players = context.CreateObjectSet<Player>().Include("Team")

                    .Where(x => x.Team.Name == "Indianapolis Colts")

                    .ToList();

players.ForEach(x => Console.WriteLine(x .Name + " - " + x.Team.Name));

context.Dispose();

And that’s it.

While I was working on this sample I bumped into quite a few common scenarios which are not yet supported. Seeing how this is an early CTP, I suppose that is to be expected. That said, I am excited to see the direction it is taking and look forward to learning more as I have time to work with it.

For more information take a look at the related EF posts on the ADO.NET team blog.

Anyway, I download the new version and for the life of me could not figure out why the fetch the blasted thing kept giving me 401’s. You know, the type of scenario when you strip out all asp.net security, grant ‘everyone’ full control of the entire website file system and run SysInternals procmon. Ya one of those.

So here was the deal: (right click js –> properties –> advanced)

I don’t know how or why that box gets checked, but if it is, then IIS will not read the file. Period.

So don’t check it

Well, sometimes life just kicks you in the balls.

Lets rewind to January of 2009. My wife Katy and I own 3 properties, one we live in, one was on the market for sale (wife’s old condo), and one was being rented. (all of them upside down, go economy! woo!)

On January 25th we found the one that was vacant flooded! The line that was connected to the icemaker had broken off the fridge and had been running for 3 weeks. It ruined the house, nearly 40k worth of damage. Luckily insurance covered the repairs, but what a timesuck mess, and we are still fixing things today (we live there now).

If that isn’t bad enough, we get a call in late February from the police that the tenants in our rental house have been arrested for drugs! After evicting them and viewing the property, we were in shock. The house was completely thrashed! Full of trash, holes in walls & doors, urine soaked carpets, counter tops burnt and chipped. Since this was strike 2,  PARK PLACE PROPERTY MANAGEMENT IN BOISE IDAHO WAS SO FIRED!

The house needed renovating, and we couldn’t afford to hire someone. So we did it ourselves. Katy made this cool slideshow, so I thought I would share it with you.

Here is what we did (more or less)

• Ripped out carpet, treated sub-floor for odor
• Replaces 3 doors, including front door (door installer, I salute you!)
• Tiled countertops
• Spray all cabinets and trim
• Paint entire interior, including ceiling & doors
• Re-grout shower/bathtub tile
• Replace all interior light fixtures
• Replace bathroom vanity
• Replace fridge main board & shelving
• Install new sink & faucet
• Install new dishwasher
• Install new oven/range
• All new carpet & vinyl installed
• Have driveway poured on side of house to meet parking reqs (city violated us) 
• Have new fence in backyard installed for privacy
• Had some electrical brought to code
• Installed new smoke detector system

Probably some more stuff, but you get the idea, a complete flip.

The house came out amazing and is currently rented by a small family who really likes the place. All of this cost us about 12k, and nearly 6 mos of every weekend and 2-3 weeknights per week. (I took off a weekend for Boise code camp!)

It really was a test of all tests. Katy and I look back and still cant believe we did it, 2 engineers at that. Most people I think would have quit, given the house(es) back to the bank. We are not most people

… and for the encore, I quit my day job and started my own company.

I have been trying to wrap my head around the role of the DTO in DDD. My reading of Fowler and Evans seems to indicate that you ought to have your domain objects themselves mapping into your database, rather than dedicated function-less DTOs. Relying on DTOs that are then handled by Services seems to lead to what Fowler calls The Anemic Domain Anti-Pattern: http://martinfowler.com/bliki/AnemicDomainModel.html

However, I have a tough time writing Entity classes that operate in that manner that don’t end up rather painful to change and extend.

Since you recommend the practice of using DTOs, do you have any thoughts on the subject?

Thank you for the question Scott, of course I have thoughts on this

Disclaimer: This sort of architecture is not applicable to many systems, use the right patterns and tools for the job!

I agree that an anemic domain model is bad, if there is no behavior then what’s the point right? Let’s make sure I am on the same page here:

DTO: To me, a DTO moves data between ‘tiers’. They are the packaged data ready for transport. A WCF data contract is a perfect example of a DTO, I also see a JSON object as a DTO.

Read model: This would be a different model than your real Domain model.  A Read model is very lightweight, ‘thin’ and anemic.  Its purpose is to serve aggregated data to a specific screen or message. A DTO, to me, can be a read model, as too could be a View Model.

The domain model is rich and full of behavior. This model is most valuable when performing complex business rules during the saving and updating of data within a given transaction. It can also be used to read data too, but consider this contrived example:

Let’s say that we want to display the top 10 products. The products include the Manufacturer Name, Product Name, Vendor Name,  Product Price,  Customer Ranking. Being that we are good modelers we come up with something like the following entities: Vendor, Manufacturer, Product,  &  ProductRanking (maybe localization & currency support tables too).

If I use my domain model to get this data, I am going to end up retrieving quite a bit more data than I actually need, which could degrade performance. Not to mention having to deal with dot notation everywhere foo.Name =a.b.c.d. 

We only need 5 fields, and they are immutable for this operation.

My preference is to materialize the read model (DTO, View Model) by projecting from the Domain Model, or by using a Stored Procedure for more complicated recursive, spatial or temporal queries.

Splitting the models allows the reads & writes to fluctuate independently, so which leads to higher maintainability. These models can also run on different tiers/nodes to increase scalability (read/cache tier, write tier).

At some point, whether off a view or an inbound DTO, there will be mapping back into the domain model. This ‘friction’ or ‘impedance’ is pretty easy to manage using an assembler/translator, or a tool like AutoMapper.

Greg Young & Udi Dahan take this concept further and apply a programming principle called Command-Query Separation with distributed programming and SOA. I think it is very good stuff.

Here are some posts that are all somewhat related:
http://jonathan-oliver.blogspot.com/2009/03/dddd-and-cqs-getting-started.html
http://www.udidahan.com/2008/08/11/command-query-separation-and-soa/
http://codebetter.com/blogs/gregyoung/archive/2009/08/13/command-query-separation.aspx
http://elegantcode.com/2008/04/27/dtos-or-serialized-domain-entities/
http://elegantcode.com/2008/04/30/altnet-seattle-takeawayddddresources/

• Retrieve data by aggregate roots, have a repository for each root. The root queries should return the entire aggregate. If you are going to defer loading to a part of the root graph, be explicit. Instead of lazy loading Foo.Bars, I like to say Foo.LoadBars() <- yes seriously
• Learn how to identify the right aggregate
• Respect your aggregate root boundaries. Aggregates cannot call into other aggregates children! You shouldn’t be adding a product from the order, really, this is bad: LineItem.Product.Calatalog.Add(new Product). The order AR just crossed into the Catalog AR. Its not the job of the Order to add products to the catalog
• Do not try an overuse an aggregate, its ok to create a new one. Less is more does not apply. Fulfilling an order is different than placing one, and your data access may need to reflect that
• Use a ‘Read Model’. The most common approach here is using DTO or ViewModel, and projecting straight into it from the object model query or database
• For complex queries that perform aggregations and calculations, consider using a store procedure. They really have their place, even with the best ORM’s (then project into Read Model)
• Avoid putting query logic in mappings (Assembler’s, Translators, AutoMapper)
• Use a tracing tool. I like the SQL trace profiler, but if you are not as comfortable with sql, there is a some good profilers around, like NHProf for nHiberante & soon EFProf for the Entity Framework
• Know the SQL that is going to your database. Have your tests emit the generated sql out to the console. Live it, learn it, love it. You should know your ORM tendencies, especially if you are using a linq provider
• Batch requests to your services and database, especially if you are in a web or distributed environment

I’ve seen this one all too many times:

Business guy: The order checkout screen is running slow in production

Dev: It shouldn’t be, it runs great on my machine

Business guy: Well, it is. It takes 10-15 seconds to load order 123

Dev: Let me check, ya hmm, it is slow. I’ll look into it

The developer proceeds to crack open the source where he finds some LOD nightmare data binding mess in the view, or the mapping to the presentation model: “Customer.Order-> LineItem.Product.Catalog.Vendor.Name”

Because someone wanted to display the Vendor name on the line detail, they just hopped over the graph and loaded the catalog, and then vendor. So here comes the entire catalog! (of course its N + 1)

Why did they do that? Because it is EASY! (and because your boss wanted it yesterday)

The team never knows about it until it’s too late. Yep, it runs fast locally, because we developers only have a small catalog on our machine, I mean “we don’t want all that data on our box”.

Now I know there are many folks out there saying “Well that’s just stupid, I would never do that”. Maybe you wouldn’t, but that guy sitting next to you, he will. I tell you, we all do it, again and again.

The result over time is an interconnected web of queries that can bring a system to a crawl.

See my follow up post for some tips I use when designing a data access layer with an ORM