Think Before Coding

To content | To menu | To search

Tag - Repository

Entries feed - Comments feed

Monday, November 2, 2009

Event Sourcing and CQRS, Let's use it.

Last time, we started a very basic Event Sourcing/Domain Events/CQRS framework. Be careful, I made an edit in the nested DomainEvents+Handler<T>.Handles<E>() method, the AggregateRoot.Replay method will not work as is, but we won’t need it.

We’ll build an equally simplistic application for personal library management.

The Ubiquitous Language will be minimal.

A Book can be Registered with a Title and an ISBN.

A Book can be Lent to a Borrower at some Date for an Expected Time Span.

A Book can then be Returned. If it is Returned after Expected Time Span, the return is Late.

That’s enough for our first try.

The Command Context

The State Change Events

Here is the code for the three events that we found in the Ubiquitous language:

    public class BookRegistered

    {

        public readonly BookId Id;

        public readonly string Title;

        public readonly string Isbn;

 

        public BookRegistered(BookId id, string title, string isbn)

        {

            Id = id;

            Title = title;

            Isbn = isbn;

        }

    }

 

    public class BookLent

    {

        public readonly BookId Id;

        public readonly string Borrower;

        public readonly DateTime Date;

        public readonly TimeSpan ExpectedDuration;

 

        public BookLent(BookId id, string borrower, DateTime date,

               TimeSpan expectedDuration)

        {

            Id = id;

            Borrower = borrower;

            Date = date;

            ExpectedDuration = expectedDuration;

        }

    }

 

    public class BookReturned

    {

        public readonly BookId Id;

        public readonly string By;

        public readonly TimeSpan After;

        public readonly bool Late;

 

        public BookReturned(BookId id, string @by, TimeSpan after,

             bool late)

        {

            Id = id;

            By = by;

            After = after;

            Late = late;

        }

    }

These events will usually be serialized to the event storage and on a service bus, but here everything runs in memory.

The Book Aggregate Root

The book will need to be referenced by an identity in our system. We’ll hide a Guid behind a BookId struct :

    public struct BookId : IEquatable<BookId>

    {

        private Guid id;

 

        private BookId(Guid id) { this.id = id; }

 

        public static BookId NewBookId() { return new BookId(Guid.NewGuid()); }

 

        public bool Equals(BookId other) { return other.id.Equals(id); }

 

        public override bool Equals(object obj)

        {

            if (ReferenceEquals(null, obj)) return false;

            if (obj.GetType() != typeof(BookId)) return false;

            return Equals((BookId)obj);

        }

 

        public override int GetHashCode() { return id.GetHashCode(); }

    }

Now, the Book class itself :

  public class Book : AggregateRoot<BookId>

  {

      private readonly BookId id;

      private string title;

      private string isbn;

      private string borrower;

      private DateTime date;

      private TimeSpan expectedDuration;

 

      public Book(BookId id, IEnumerable<object> events)

      {

          this.id = id;

          foreach (dynamic @event in events)

              Apply(@event);

      }

 

      public Book(BookId id, string title, string isbn)

      {

          this.id = id;

          var @event = new BookRegistered(id, title, isbn);

          Apply(@event);

          Append(@event);

      }

 

      public override BookId Id { get { return id; } }

 

      public void Lend(string borrower, DateTime date,

                              TimeSpan expectedDuration)

      {

          if (this.borrower != null)

              throw new InvalidOperationException("The book is already lent.");

          var @event =

                new BookLent(id, borrower, date, expectedDuration);

          Apply(@event);

          Append(@event);

      }

 

      public void Return(DateTime returnDate)

      {

          if (borrower == null)

              throw new InvalidOperationException("The book has not been lent.");

          if (returnDate < date)

              throw new ArgumentException(

                "The book cannot be returned before being lent.");

          var actualDuration = returnDate - date;

          var @event = new BookReturned(

                         id,

                         borrower,

                         actualDuration,

                         actualDuration > expectedDuration);

          Apply(@event);

          Append(@event);

      }

 

      private void Apply(BookRegistered @event)

      {

          title = @event.Title;

          isbn = @event.Isbn;

      }

 

      private void Apply(BookLent @event)

      {

          borrower = @event.Borrower;

          date = @event.Date;

          expectedDuration = @event.ExpectedDuration;

      }

 

      private void Apply(BookReturned @event)

      {

          borrower = null;

      }

  }

The class implements AggregateRoot<BookId> and so provides an explicitly implemented UncommittedEvents property.

The first .ctor is used to load the Aggregate Root, the second one is used to build a new Aggregate Root.

The public methods (Lend and Return) are the commands on the Aggregate Root as defined in the Ubiquitous Language.

The structure is always the same :

  1. Validate arguments and state
  2. Prepare state transition using domain logic
  3. Apply state transition (no domain logic should happen here)
  4. Append state transition to uncommitted events

The first .ctor uses dynamic to dispatch each event object on the corresponding specific Apply method. In case you implement the pattern is previous C# version, it is advised to provide a Replay method in the base class that will perform the dynamic dispatch based on reflection.

That’s all for the entity. No ORM, no mapping… easy.

The Repository

It is often clearer to provide a specific repository interface that exposes only available methods. With event sourcing, it’s not that useful… we’ll write it anyway in case you’d like to use dependency injection. The interface is part of the domain and should be in the same assembly as the entity and the events.

    public interface IBookRepository

    {

        void Add(Book book);

        Book this[BookId id] { get; }

    }

The implementation will simply derive from the Repository base class, it can be in the application assembly.

    internal class BookRepository :

        Repository<BookId, Book>,

        IBookRepository

    {

        protected override Book CreateInstance(BookId id,

            IEnumerable<object> events)

        {

            return new Book(id, events);

        }

    }

Add and the indexer are implemented by the base class. The only thing to provide is a way to instantiate the class with expected parameters.

We could use Activator.CreateInstance or reflection to provide a generic implementation. I choose to make it simpler to read.

The Query context

The Report Database

We’ll mimic a reporting table of book lent state :

This would be the data returned from table rows :

    public class BookState

    {

        public BookId Id { get; set; }

        public string Title { get; set; }

        public bool Lent { get; set; }

    }

And this will hide the data table implementation :

    public interface IBookStateQuery

    {

        IEnumerable<BookState> GetBookStates();

        BookState GetBookState(BookId id);

        IEnumerable<BookState> GetLentBooks();

 

        void AddBookState(BookId id, string title);

        void SetLent(BookId id, bool lent);

    }

We can simply query data to report in the UI, and update data state.

Implementation will be in memory for now :

    class BookStateQuery : IBookStateQuery

    {

        private readonly Dictionary<BookId, BookState> states =

                     new Dictionary<BookId, BookState>();

 

        public IEnumerable<BookState> GetBookStates()

        {

            return states.Values;

        }

 

        public BookState GetBookState(BookId id)

        {

            return states[id];

        }

 

        public IEnumerable<BookState> GetLentBooks()

        {

            return states.Values.Where(b => b.Lent);

        }

 

        public void AddBookState(BookId id, string title)

        {

            var state = new BookState { Id = id, Title = title };

            states.Add(id, state);

        }

 

        public void SetLent(BookId id, bool lent)

        {

            states[id].Lent = lent;

        }

    }

The important point here is that no domain logic occurs.

A RDBMS implementation could use an ORM or simply build DTOs from a DataReader.

The event handlers

We can now denormalize domain states to the reporting database using an event handler :

    class BookStateHandler :

    Handles<BookRegistered>,

    Handles<BookLent>,

    Handles<BookReturned>

    {

        private readonly IBookStateQuery stateQuery;

 

        public BookStateHandler(IBookStateQuery stateQuery)

        {

            this.stateQuery = stateQuery;

        }

 

        public void Handle(BookRegistered @event)

        {

            stateQuery.AddBookState(@event.Id, @event.Title);

        }

 

 

        public void Handle(BookLent @event)

        {

            Console.WriteLine("Book lent to {0}", @event.Borrower);

            stateQuery.SetLent(@event.Id, true);

        }

 

        public void Handle(BookReturned @event)

        {

            Console.WriteLine("Book returned by {0}", @event.By);

            stateQuery.SetLent(@event.Id, false);

        }

    }

The Console.WriteLine are here to view when things happen, you would usually not use it in your production code. Logging this would not provide much benefits since all the events are already stored in the EventStorage.

Using this handler, the IBookStateQuery will be up to date with current Command Context state. In an asynchronous environment, this is where eventual consistency is introduced.

We will also add a service that will notify when a user returned a book too late :

    class LateReturnNotifier :

    Handles<BookReturned>

    {

        public void Handle(BookReturned @event)

        {

            if (@event.Late)

            {

                Console.WriteLine("{0} was late", @event.By);

            }

        }

    }

Here again, no domain logic, we just do the infrastructure stuff, usually sending an email or a SMS.

View it in Action

    class Program

    {

        static void Main(string[] args)

        {

            ISessionFactory factory = new SessionFactory(new EventStorage());                IBookStateQuery query = new BookStateQuery();

 

            DomainEvents.RegisterHanlder(() => new BookStateHandler(query));

            DomainEvents.RegisterHanlder(() => new LateReturnNotifier());

 

            var bookId = BookId.NewBookId();

            using (var session = factory.OpenSession())

            {

                var books = new BookRepository();

                books.Add(new Book(bookId,

                   "The Lord of the Rings",

                   "0-618-15396-9"));

                session.SubmitChanges();

            }

 

            ShowBooks(query);

 

            using (var session = factory.OpenSession())

            {

                var books = new BookRepository();

                var book = books[bookId];

                book.Lend("Alice",

                     new DateTime(2009, 11, 2),

                     TimeSpan.FromDays(14));

 

                session.SubmitChanges();

            }

 

            ShowBooks(query);

 

 

            using (var session = factory.OpenSession())

            {

                var books = new BookRepository();

                var book = books[bookId];

                book.Return(new DateTime(2009, 11, 8));

 

                session.SubmitChanges();

            }

 

            ShowBooks(query);

 

 

            using (var session = factory.OpenSession())

            {

                var books = new BookRepository();

                var book = books[bookId];

                book.Lend("Bob",

                      new DateTime(2009, 11, 9),

                      TimeSpan.FromDays(14));

 

                session.SubmitChanges();

            }

 

            ShowBooks(query);

 

 

            using (var session = factory.OpenSession())

            {

                var books = new BookRepository();

                var book = books[bookId];

                book.Return(new DateTime(2010, 03, 1));

                session.SubmitChanges();

            }

 

            ShowBooks(query);

        }

 

        private static void ShowBooks(IBookStateQuery query)

        {

            foreach (var state in query.GetBookStates())

                Console.WriteLine("{0} is {1}.",

                       state.Title,

                       state.Lent ? "lent" : "home");

        }

    }

We start by instantiating storage for the command context (the ISessionFactory) and the query context (the IBookStateQuery). In production you’ll use persistent storages (a persistent event storage and a RDBMS). I highly recommend using a Dependency Injection Container for real size projects.

Then we wire the handlers on domain events.

The application can start.

  • We register a book in the library.
  • We lend it to Alice on 2009-11-02 for 14 days
  • She returns it on 2009-11-08, she’s on time
  • We lend it to Bob on 2009-11-09 for 14 days,
  • He returns it on 2010-03-01, he’s late

The output is the following :

The Lord of the Rings is home.    // written from state

Book lent to Alice                // written by the book state handler

The Lord of the Rings is lent.    // written from state

Book returned by Alice            // written by the book state handler

The Lord of the Rings is home.    // written from state

Book lent to Bob                  // written by the book state handler

The Lord of the Rings is lent.    // written from state

Book returned by Bob              // written by the book state handler

Bob was late                      // written by the late return notifier

The Lord of the Rings is home.    // written from state

We have here a clear separation between Command that handles the domain logic and Query that handles presentation logic.

Have fun. Questions and remarks expected !

Friday, October 30, 2009

Event Sourcing and CQRS, Now !

Enough talking, Action !

Today, we will build a basic event sourcing infrastructure. Get the beta 2 of Visual Studio 2010, we’ll be using C# dynamic features to go straight to our goal.

Then Event Storage

Let’s hide the ugly details of the event storage behind two simple interfaces :

    public interface IEventStorage : IDisposable

    {

        IAggregateRootStorage<TId> GetAggregateRootStore<TAggregateRoot, TId>()

            where TAggregateRoot : AggregateRoot<TId>;

    }

 

    public interface IAggregateRootStorage<in TId>

    {

        void Append(TId id, IEnumerable<object> events);

        IEnumerable<object> this[TId id] { get; }

    }

And we start with a minimal in memory implementation, the event storage first :

    public class EventStorage : IEventStorage

    {

        private readonly Dictionary<Type, dynamic> stores = new Dictionary<Type, dynamic>();

 

        public IAggregateRootStorage<TId> GetAggregateRootStorage<TAggregateRoot, TId>()

           where TAggregateRoot : AggregateRoot<TId>

        {

 

            dynamic store;

            if (!stores.TryGetValue(typeof(TAggregateRoot), out store))

            {

                store = new AggregateRootStorage<TId>();

                stores.Add(typeof (TAggregateRoot), store);

            }

            return store;

        }

 

        public void Dispose()

        {

            stores.Clear();

        }

    }

Here I could replace dynamic by object, and cast to requested type on return. I use dynamic because this kind of code is not compile time safe anyway. There’s a specific storage for each Aggregate Root type, especially depending on identifier type, for type safety.

Then the AggregateRootStorage :

    class AggregateRootStorage<TId> : IAggregateRootStorage<TId>

    {

        private readonly Dictionary<TId, List<object>> store = new Dictionary<TId, List<object>>();

 

        public void Append(TId id, IEnumerable<object> events)

        {

            List<object> aggregateRootEvents;

            if (!store.TryGetValue(id, out aggregateRootEvents))

            {

                aggregateRootEvents = new List<object>();

                store.Add(id, aggregateRootEvents);

            }

 

            aggregateRootEvents.AddRange(events);

        }

 

        public IEnumerable<object> this[TId id]

        {

            get { return store[id]; }

        }

    }

It simply stores list of events associated with aggregate root identifier.

The Aggregate Root

Aggregate roots manage uncommitted events :

    public interface IUncommittedEvents : IEnumerable<object>

    {

        bool HasEvents { get; }

        void Commit();

    }

The interface can indicates whether there are events, returns the events, and clears the uncommitted events by committing.

Quick implementation :

    internal class UncommittedEvents : IUncommittedEvents

    {

        private readonly List<object> events = new List<object>();

 

        public void Append(object @event)

        {

            events.Add(@event);

        }

 

        IEnumerator<object> IEnumerable<object>.GetEnumerator()

        {

            return events.GetEnumerator();

        }

 

        public bool HasEvents

        {

            get { return events.Count != 0; }

        }

 

        void IUncommittedEvents.Commit()

        {

            events.Clear();

        }

 

        IEnumerator IEnumerable.GetEnumerator()

        {

            return events.GetEnumerator();

        }

    }

Nothing tricky here neither.

Now, the IAggregateRoot interface used by the repository gives access to the uncommitted events:

    public interface IAggregateRoot<out TId>

    {

        TId Id { get; }

        IUncommittedEvents UncommittedEvents { get; }

    }

The AggregateRoot class will maintain the uncommitted events :

    public abstract class AggregateRoot<TId> : IAggregateRoot<TId>

    {

        private readonly UncommittedEvents uncommittedEvents = new UncommittedEvents();

 

        protected void Replay(IEnumerable<object> events)

        {

            dynamic me = this;

            foreach (var @event in events)

                me.Apply(@event);

        }

 

        protected void Append(object @event)

        {

            uncommittedEvents.Append(@event);

        }

 

        public abstract TId Id { get; }

 

        IUncommittedEvents IAggregateRoot<TId>.UncommittedEvents

        {

            get { return uncommittedEvents; }

        }

    }

The Append method will be use by child class to append events after they are applied.

The Replay method is used in the child class constructor to rebuild the Aggregate Root state from events.

Here I use a dynamic me variable to dispatch events on specific child class Apply methods. A .Net 2 or 3.5 implementation would use reflection to dispatch events on Apply methods.

The UncommittedEvents property is implemented explicitly so that it does not appear in standard class use.

The Repository

The repository is just very slightly longer. I added a session concept so that several repositories can submit changes in a single transaction :

    internal interface ISessionItem

    {

        void SubmitChanges();

    }

 

     public abstract class Repository<TId, TAggregateRoot> : ISessionItem

        where TAggregateRoot : AggregateRoot<TId>

    {

        private readonly Dictionary<TId, TAggregateRoot> users = new Dictionary<TId, TAggregateRoot>();

        private readonly IAggregateRootStorage<TId> aggregateRootStorage;

 

        protected Repository()

        {

            aggregateRootStorage = Session.Enlist(this);

        }

 

        public void Add(TAggregateRoot user)

        {

            users.Add(user.Id, user);

        }

 

        public TAggregateRoot this[TId id]

        {

            get { return Find(id) ?? Load(id); }

        }

 

        private TAggregateRoot Find(TId id)

        {

            TAggregateRoot user;

            return users.TryGetValue(id, out user) ? user : null;

        }

 

        private TAggregateRoot Load(TId id)

        {

            var events = aggregateRootStorage[id];

            var user = CreateInstance(id, events);

 

            users.Add(id, user);

 

            return user;

        }

 

        protected abstract TAggregateRoot CreateInstance(TId id, IEnumerable<object> events);

 

        public void SubmitChanges()

        {

            foreach (IAggregateRoot<TId> user in users.Values)

            {

                var uncomitedEvents = user.UncommittedEvents;

                if (uncomitedEvents.HasEvents)

                {

                    aggregateRootStorage.Append(user.Id, uncomitedEvents);

                    PublishEvents(uncomitedEvents);

                    uncomitedEvents.Commit();

                }

            }

            users.Clear();

        }

 

        protected void PublishEvents(IUncommittedEvents uncommittedEvents)

        {

            foreach (dynamic @event in uncommittedEvents)

                DomainEvents.Raise(@event);

        }

 

    }

The constructor enlist the repository in current session.

The Add method registers the aggregate root in the repository, its events will be persisted in SubmitChanges()

The indexer finds an entity already in memory or loads it from the event store. The abstract CreateInstance method implementation will be responsible for instantiation.

Submit changes does what is expected, and also publish committed events. Will see the trick with dynamic @events when we analyze domain events.

The Session and its Factory

Just to group the SubmitChanges on several repositories :

    public interface ISessionFactory : IDisposable

    {

        ISession OpenSession();

    }

 

    public class SessionFactory : ISessionFactory

    {

        private readonly IEventStorage eventStorage;

 

        public SessionFactory(IEventStorage eventStorage)

        {

            this.eventStorage = eventStorage;

        }

 

        public ISession OpenSession()

        {

            return new Session(eventStorage);

        }

 

        public void Dispose()

        {

            eventStorage.Dispose();

        }

    }

 

    public interface ISession : IDisposable

    {

        void SubmitChanges();

    }

 

    public class Session : ISession

    {

        private readonly IEventStorage eventStorage;

        private readonly HashSet<ISessionItem> enlistedItems = new HashSet<ISessionItem>();

 

        [ThreadStatic] private static Session current;

 

        internal Session(IEventStorage eventStorage)

        {

            this.eventStorage = eventStorage;

            if (current != null)

                throw new InvalidOperationException("Cannot nest unit of work");

 

            current = this;

        }

 

        private static Session Current

        {

            get { return current; }

        }

 

        public void SubmitChanges()

        {

            foreach (var enlisted in enlistedItems)

                enlisted.SubmitChanges();

 

            enlistedItems.Clear();

        }

 

        public void Dispose()

        {

            current = null;

        }

 

        internal static IAggregateRootStorage<TId> Enlist<TId, TAggregateRoot>

                        (Repository<TId, TAggregateRoot> repository)

            where TAggregateRoot : AggregateRoot<TId>

        {

            var unitOfWork = Current;

            unitOfWork.enlistedItems.Add(repository);

            return unitOfWork.eventStorage.GetAggregateRootStorage<TAggregateRoot, TId>();

        }

    }

Ok almost everything is here. The last part, for events to be used by other parts of the system, needed to go CQRS.

Domain Events

Here, I made a minor variation on Udi Dahan’s DomainEvents implementation :

public static class DomainEvents

    {

        [ThreadStatic] private static List<Delegate> actions;

 

        private static List<Handler> handlers;

 

        public static void Register<T>(Action<T> callback)

        {

            if (actions == null) actions = new List<Delegate>();

            actions.Add(callback);

        }

 

        public static void RegisterHanlder<T>(Func<T> factory)

        {

            if (handlers == null) handlers = new List<Handler>();

            handlers.Add(new Handler<T>(factory));

        }

 

        //Raises the given domain event      

        public static void Raise<T>(T @event)

        {

            if (actions != null)

                foreach (Delegate action in actions)

                    if (action is Action<T>)

                        ((Action<T>) action)(@event);

 

            if (handlers != null)

                foreach (var h in handlers)

                {

                    if (h.Handles<T>())

                    {

                        var handler= h.CreateInstance<T>();

                        handler.Handle(@event);

                    }

                }

        }

 

        private abstract class Handler

        {

            public abstract bool Handles<E>();

            public abstract Handles<E> CreateInstance<E>();

        }

 

        private class Handler<T> : Handler

        {

 

            private readonly Func<T> factory;

 

            public Handler(Func<T> factory)

            {

                this.factory = factory;

            }

 

            public override bool Handles<E>()

            {

                return typeof (Handles<E>)

                   .IsAssignableFrom(typeof (T));

            }

 

            public override Handles<E> CreateInstance<E>()

            {

                return (Handles<E>)factory();

            }

        }

    }

 

    public interface Handles<in T>

    {

        void Handle(T @event);

    }

Edit : Changed the Handles<E>, T should be casted as Handles<E>, not as E, of course.

Event handlers can be registerd as Action<T> delegates or as class that implements once or more Handles<T>.

The private Handler and Handler<T> classes are used to find handlers that handles a specific message and dispatch it, without using a Dependency Injection Container like Udi’s implementation.

The simple dynamic-fu in the repository was to call DomainEvents.Raise<T> using a dynamic dispatch. This way, Raise is always called with the actual event type in T. No tricky reflection is needed for the dispatch. inside Raise<T>, we can the rely on T as being the actual event type. Funky !

Next Time…

There’s already a lot of code for a single post, every thing is in place at infrastructure level. You can already try it for yourself if you can figure how to.

The sample will come in the next post, stay tuned.

Wednesday, April 8, 2009

Back on Repositories and Paging. Introducing reporting.

I had quite a lot of comments on my previous post on repositories and paging, and there’s a lot of people coming from google looking for answers… It’s sign that there’s no good response to this issue now.

The problem was how paging (a presentation concern) fits into a repository that should have only domain concerns…

And the short answers is… It doesn’t fit !

It doesn’t mean you should forget everything I told you before but there’s a vision change.

There’s something missing in DDD book…

but present in current discussion about DDD. The book provides good building blocks (entities, repository…) but Evans says himself it has been a bit over emphasized. The book is mainly about maintaining and mutating your domain state, not about it’s presentation.

CQS to the rescue

The CQS (Command Query Separation) principle proposes to decouple Commands that change the state of the system, from Queries that ask the state of the system.

The repository lies on the Command side, that’s why :

  • It should be specialized to express only mutations that are possible for the system
  • It should not expose presentation concerns like paging

But what’s on the Query side ?

The query side should be far more supple and provide tools to query the state of the domain. It can even be implemented with IQueryable interfaces to provide that flexibility. Asking for pages in this area is natural since you just want to query a part of the domain state.

The goal of all this is to report the state of the system. So Reporting is a good name here.

You can read Greg Young’s DDDD posts to see where CQS can lead : Write only domain model (Commands) and rich scalable distributed Query mechanisms using messaging.

There’s no clear guidance yet in this field but I’m still investigating. The flexibility of a reporting service in the domain layer is still a huge gain to understand where each concept fits.

Wednesday, March 4, 2009

How *not* to inject services in entities

syringeI’ve seen lot of people asking where and how to inject services in entities. The services in question are often repositories by the way…

The response is simple :

 - DO NOT inject services in entities !

- Ok I see, you’re against dependency injection

- NO, I'm not against dependency injection, I use it a lot.

- You can still use a static service locator…

- I avoid service locator when I can, especially when the service locator must be static…

– So you’ll get an anemic object model !

- I don’t think so.

 

Injecting services in entities is wrong

You’ll find me a bit presumptuous, but I say it again : Injecting services in entities is wrong.

Nesting objects is not a problem from an OO point of view, but we’re talking about a special kind of objects, entities.

 

Entities are all about their state management, and this state management can require several objects.

  • Code infrastructure objects like lists or dictionary to handle collection of data,
  • Object oriented constructs to leverage code maintenance techniques like strategies.

Entities don’t have to be classes with public setters and getters… you should even avoid this to keep you entities in a consistent state.

But there is no reason for an entity to keep a reference on a service, since it’s not part of its state.

There are usually three situations in which people thinks they need it :

  • Lazy loads
  • Relations
  • Behavior methods

Let’s review each point…

 

Lazy loads

Sometimes, an entity property is heavy to load and is not required by all code paths. In this case, loading it upfront can lead to performance problems.

The usual way to work it out is to hold a reference to a data access object or a repository and to load and cache the requested data on demand.

 

 Using a data access layer object in the entity is clearly a break of persistence ignorance, but using a repository is not a better option.

 

The repository is a way to abstract persistence in the model, but it’s still a persistence concern even if modeled in terms of domain terms.

I’ve already posted about ways to solve this problem in Lazy load and persistence ignorance and part 2.

 

Relations

I was twitting yesterday with Kyle Baley about the need to have an Event repository in the Users entity. He wanted to get the User Team for the current event. I think you don’t need more context to understand the problem.

The User did not know about the current event so it needed the Event repository to find it and find the corresponding team.

But why does the User entity expose a CurrentTeam property if it doesn’t know about Events ? There’s something missing here.

The whole picture becomes clearer if you add a Participant entity that embodies the participation of a user to an Event, and no repository is needed anymore since you don’t need a CurrentTeam property on User.

 Make relations clear instead of hiding it in repositories.

 

Behavior methods

If I have mail message entity and I want a Send method on it ?

Tiding your entity to the service that will use it is not conceptually satisfying. The server that will send the message is a medium and is not part of the entity itself.

It’s seems better to call server.Send(message).

The problem is that you can end breaking the tell don’t ask principle because the Send method will ask the message for each property value. And you can be tempted to put computations that should be in the message entity inside the Send method.

 

Let’s call Double Dispatch to the rescue !

  • Design a server interface presenting a Send method that take the parameters it need (title, recipients, message body…)
  • Add a SendThrough method to your entity that takes the server interface as parameter
  • Implement SendTrhough so that it computes values to pass to the Send method
  • That’s it.

 

Here is a small sample implementation :

    public interface IMailService

    {

        void Send(string sender, string recipient, string subject, string body);

    }

 

    public class Message

    {

        //...

        public void SendThrough(IMailService mailService)

        {

            string subject = isReply ? "Re : " + title : title;

            mailService.Send(sender, recipient, subject, GetMessageBody(content));

        }

    }

The entity is not tied to the service before needed. So no need for injection.

 

Is injection useless ?

There is no problem to inject services with other services, and it’s even easier since services have no state, they only need their dependencies in constructor, and to my opinion it’s the cleanest injection mode.

Usually domain services will need infrastructure services dependencies, and in this case a dependency injection framework can make things easier.

Following the preceding advice, you’ll never need to use your dependency injection framework as a service locator, and you’ll never have to perform buildups on your entities, and you’ll feel much better.

 

What’s your way to deal with it ?

For now I’ve always find a way to get rid of services inside entities, but I really would like to hear cases where you’re stuck with it to see if another way is possible, or cases where you think there is really a good reason to go this way.

Sunday, February 8, 2009

Lazy loads and persistence ignorance (Part 2)

In the previous post, I introduced a class to manage function injection for lazy loads to enable persistence ignorance.

Chris was asking where the builder I was talking about should be used, and I tumbled on a StackOverflow question asking how to make lazy loading without using classes like Lazy<T>...

I'll discuss the second part first.

There is a good way to make lazy loading without using classes like that. You can use proxies.

There are two main ways to make transparent proxies

  • by creating dynamically a derived class using Reflection.Emit
  • by creating a transparent proxy

Still there are some drawbacks with both approaches. For the first one, all your members should be made virtual, for the second your class should inherit from MarshalByRefObject. In all case you should then take care not to mess up between proxies and underlying classes.

The main critic to refuse to use Lazy<T> class is usually that it's not a domain concept, and that it leaks persistence concern in the model.

I reject those critics.

Have you ever seen someone criticize List<T> or Dictionary<,> because it was not a domain concept ? We're writing OO code, and we can use basic tooling to make our models expressive. IEnumerable<T> and Linq to objects are good examples of these useful tools.

And I don't consider that Lazy<T> is a persistence concern. It expresses that the relation between entities is a bit more loose than others. There is nothing in the Lazy<T> signature that ties your entity to any persistence concept. You just provide a way to give the value of the property when needed rather than at construction, but this choice comes from outside of your entity.

And at least it becomes clearer than with derived proxies where the C# keyword virtual is used to express something but tries to hide it in the same time.

 

For Chris question, I use the builder in the repository.

The repository is responsible for retrieving entities from the data store. The reconstruction of objects is a bit different from the construction. This is underlined in Evan's book in the chapter Factories / Reconstituting Stored Objects.

In my data access layer I use a IDataBuilder<T> interface that represents a service that can build an object of type T from a IDataRecord. This is when I work directly with the ADO.Net and stored procedures.

    public interface IDataBuilder<T>

    {

        T Build(IDataRecord record);

    }

 

I also use a class that encapsulate the access to the stored procedures (or queries if you don't want to use stored procedures).

    public class DataAccess

    {

        public UniqueResult<Entity> GetEntity(Guid id);

        {

            //...

        }

 

        public MultipleResult<Entity> GetEntities()

        {

            //...

        }

    }

 

UniqueResult<T> and MultipleResult<T> provides a methods that take a builder to read data records :

    public struct UniqueResult<T>

    {

        public T With(IDataBuilder<T> builder)

        {

            //...           

        }

    }

 

    public struct MultipleResult<T>

    {

        public IEnumerable<T> With(IDataBuilder<T> builder)

        {

            //...           

        }

    }

 

In your repository implementation you can then use all this :

    // The concrete repository interface that belongs to the domain

    public interface IEntityRepository : IEnumerable<Entity>

    {

        Entity this[Guid id] { get;}

        //.. other methods

    }

 

    // the implementation that is not part of the domain

    // an that is pesistance dependant.

    internal class EntityRepository : IEntityRepository

    {

        private DataAccess dataAccess;

        private EntityBuilder builder;

 

        public EntityRepository(DataAccess dataAccess, EntityBuilder builder)

        {

            this.dataAccess = dataAccess;

            this.builder = builder;

        }

 

        public IEnumerator<Entity> GetEnumerator()

        {

            return dataAccess.GetEntities().With(builder);

        }

 

        IEnumerator IEnumerable.GetEnumerator()

        {

            return GetEnumerator();

        }

 

        public Entity this[Guid id]

        {

            get { return dataAccess.GetEntity(id).With(builder); }

        }

    }

 

The last part is in the implementation of the builder.

    internal class EntityBuilder : IDataBuilder<Entity>

    {

        private DataAccess dataAccess;

 

        public EntityBuilder(DataAccess dataAccess)

        {

            this.dataAccess = dataAccess;

        }

 

        public Entity GetEntity(IDataRecord record)

        {

            var id = (Guid)record["Id"];

            return new Entity(

                id,

                Lazy.From(() => dataAccess.GetSubEntity(id)));

        }

    }

 

Of course, the repository implementation, the DataAccess class and the builder are all internal to the data access implementation. It can be in a separate Assembly or internal in a sub namespace of the main assembly depending on you module separation preferences.

When using linq, you simply don't need the DataAccess class because you can query the DataContext directly. But you can use the same pattern.

The main point is still that your Entity object knows strictly nothing about what's going on there.

Saturday, February 7, 2009

Lazy load and persistence ignorance

lazy

I often see questions about how to make lazy loads in entities, and wether using dependency injection for it.

The usual response is something like this :

    class Entity

    {

        private Guid id;

        private SubEntity subEntity;

        private IDataService dataService;

 

        public Entity(Guid id, IDataService dataService)

        {

            this.id = id;

            this.dataService = dataService;

        }

 

        public SubEntity SubEntity

        {

            get

            {

                if (subEntity == null)

                    subEntity = dataService.GetSubEntity(id);

 

                return subEntity;

            }

        }

    }

As you can see, your entity is seriously tied to your persistence problem now. Even if it accesses the persistence layer through an interface, it is not persistence ignorant anymore.

The smell is that you cannot create an in memory instance of your entity anymore without worrying about data access.

Should you sill inject the data access service, or is it useless and you should leave it null ?

So believe me : do not inject data services in your entity.

Now, how can we still have the lazy load behavior ?

Through injection. But not dependency injection, I use execution inversion of control through delegate injection.

If you give to your entity a function that will return the value when asked, it's as if you gave the value.

Let's encapsulate this in a small class :

    public class Lazy<T>

    {

        private T value;

        private Func<T> loader;

 

        public Lazy(T value)

        {

            this.value = value;

        }

 

        public Lazy(Func<T> loader)

        {

            this.loader = loader;

        }

 

        public T Value

        {

            get

            {

                if (loader != null)

                {

                    value = loader();

                    loader = null;

                }

                return value;

            }

        }

 

        public static implicit operator T(Lazy<T> lazy)

        {

            return lazy.Value;

        }

 

        public static implicit operator Lazy<T>(T value)

        {

            return new Lazy<T>(value);

        }

    }

Then you can use it like this in your entity :

    class Entity

    {

        private readonly Guid id;

        private readonly Lazy<SubEntity> subEntity;

 

        public Entity(Guid id, Lazy<SubEntity> subEntity)

        {

            this.id = id;

            this.subEntity = subEntity;

        }

 

        public Guid Id { get { return id; } }

 

        public SubEntity SubEntity

        {

            get { return subEntity; } // implicit cast here

        }

    }

The code is more straight forward, the intent is clearly visible.

One benefit here, is that the subEntity field can be marked as readonly, that is a big improvement because our entity is really immutable now. Actually the Lazy<T> is mutable, but it behaves as an immutable value.

If your entity is not immutable, you can still leverage the Lazy<T> class :

    class Entity

    {

        private readonly Guid id;

        private Lazy<SubEntity> subEntity;

 

        public Entity(Guid id, Lazy<SubEntity> subEntity)

        {

            this.id = id;

            this.subEntity = subEntity;

        }

 

        public Guid Id { get { return id; } }

 

        public SubEntity SubEntity

        {

            get { return subEntity; } // implicit cast here

            set { subEntity = value; } // implicit cast here too

        }

    }

The last part is about how you use it when instantiating the object.

When creating a new instance in a factory (not linked to database) :

            SubEntity subEntity = ...;

            Guid id = ...;

            Entity entity = new Entity(id, subEntity);

Here again, the implicit cast happen to pass the SubEntity as an already loaded Lazy<SubEntity>.

When binding the entity to the database :

    class EntityBuilder

    {

        private IDataService dataService;

 

        public EntityBuilder(IDataService dataService)

        {

            this.dataService = dataService;

        }

 

        public Entity GetEntity(Guid id)

        {

            return new Entity(

                id,

                new Lazy<SubEntity>(() => dataService.GetSubEntity(id)));

        }

    }

We can use a small helper method to make the instantiation cleaner :

    public static class Lazy

    {

        public static Lazy<T> From<T>(Func<T> loader)

        {

            return new Lazy<T>(loader);

        }

    }

Then you can write :

            return new Entity(

                id,

                Lazy.From(() => dataService.GetSubEntity(id)));

 

Now, the code that instantiate the Entity decides where the sub entity comes from.

The entity has become truly persistence ignorant.

Some would also advice not to use lazy load at all... this is still an option to consider !

Continued in Lazy loads and persistence ignorance (Part 2)

Wednesday, January 21, 2009

Mixing IEnumerable and IQueryable

Marcel posted a comment in the previous post saying that even if returning IEnumerable, the new query clauses would be executed in the database… But it’s not.

If the repository use linq internally and returns the result as IEnumerable, on the other side, consider something like this :

var selectedEntities = repository.GetAll().Where(x => x.Selected)

Where GetAll returns an IEnumerable (that is actually a IQueryable).

The Where extension method will be selected on Enumerable. Be careful, Extension methods are static methods, no virtual call is involved here. The static type of the object decide the selected extension method.

 

Check in your debugger, selectedEntities is an instance of the Enumerable.WhereIterator internal class.

 

So when enumerating it, it enumerates its source and returns every item that passes the predicate.

When enumerating the source, here the source use linq2Sql to get the items and creates a query that returns all rows from the database.

The where clause was not executed in the database.

So the Linq provider did not leak outside of the repository.

Monday, January 19, 2009

Repositories and IQueryable, the paging case.

Edit : My opinion on this subject have changed… You can read the full story in Back on Repositories and Paging. Introducing reporting.

The technique is still useful to write the query services, but I would not recommend to implement it on a repository.

 

When it comes to repositories, people have a hard time figuring how to respect the DDD vision while taking most out of current ORM technologies (Linq and ORM) and not writing too much code – we’re so lazy.civilwar

The war between IRepository<T> generic repositories or not is raging outside, and I took some time to chose my side. Here are the points to consider :

  • The repository is a contract between the domain and the infrastructure
  • The implementation details should not leak outside

In my opinion, the first point indicates that the repository should be tailored to the domain needs. It cannot be generic, or it is not a contract at all.

When writing a contract, details matter !

This doesn’t mean that we cannot use generic tools to access data behind the interface curtain. Linq DataContext and Tables<T> are very sharp tools to implement repositories. And there is a very good post by Greg Young about that.

 

There is still a point to be discussed though :

Should the repository methods return IEnumerable<T> or IQueryable<T> ?

The IQueryable<T> is part of the framework, and cleanly integrated in the language.

The problem is that its implementation depends heavily on the underlying provider. And it is a really serious leak !

So lets state the question differently :

- Why would we need IQueryable ?
- Because we can add new query clauses, and they will be executed directly in the database.

- What kind of clause would you add ?
- Don’t know… clauses…

- Would it be business specifications ?
- No, these should already be in the repository..

- So ?
- Sorting and Paging ! These are presentation concerns !

- Here’s the point.

Paging is not a recent concern for programmers and there is never enough tools to implement it properly. The main problem is that paging once you’ve got all the data is less that effective. And this is what will happen with an IEnumerable approach.

But let’s ask a two last questions.

Why is paging useful ? Is it really a presentation concern ?

We need paging to navigate through large collection of object, and if a collection can grow enough so that is cannot be embraced in a single query, it becomes a domain concern !

  • When your object collection is known at design time to stay in small bounds but you still want to page it for presentation clarity, there is no real penalty to fetch all and display only a few.
  • But when your collection can grow big, you SHOULD provide a mechanism to retrieve only a range of it, for presentation purpose or simply for batching purpose.

The problem is that if we leak IQueryable, the user can do far more than paging, and problems can arise. So I suggest to use a new interface IPaged<T> that would provide everything needed for paging :

public interface IPaged<T> : IEnumerable<T>

    {

        ///<summary>

        /// Get the total entity count.

        ///</summary>

        int Count { get; }

 

        ///<summary>

        /// Get a range of persited entities.

        ///</summary>

        IEnumerable<T> GetRange(int index, int count);

    }

 

And here is a simple implementation on a IQueryable :

public class Paged<T> : IPaged<T>

    {

        private readonly IQueryable<T> source;

 

        public Paged(IQueryable<T> source)

        {

            this.source = source;

        }

 

 

        public IEnumerator<T> GetEnumerator()

        {

            return source.GetEnumerator();

        }

 

        IEnumerator IEnumerable.GetEnumerator()

        {

            return GetEnumerator();

        }

 

        public int Count

        {

            get { return source.Count(); }

        }

 

        public IEnumerable<T> GetRange(int index, int count)

        {

            return source.Skip(index).Take(count);

        }

    }

Then your repository can return IPaged collections like this without leaking implementation details :

public IPaged<Customer> GetCustomers();

 

This seems to be a major step in the repository pattern understanding, and it’s underlying war. And you, on which side are you ?