Some more Aggregate Root thinking…

If a child entity in an Aggregate Root should not be accessible outside the boundaries of a Root, why should you be able to instantiate it?

If I mark their constructor with internal, it should be only instantiated from a Root (root should know how to instantiate it), this would also allow us to play with them only within the Model project, but others should get it via Root (like Services, Client applications and others).

Example…

public class Car : EntityBase<int>, IAggregateRoot
{
    public Car()
    {}

    public Wheel RightWheel
    {
        get
        {
            return new Wheel(”Right”);
        }
    }
}

and Wheel (child entity):

public class Wheel : EntityBase<int>
{
    private string _wheelType;

    internal Wheel(string wheelType)
    {
        _wheelType = wheelType;
    }
}

Again… my insecurities and concerns come from previous reasons as with the previous post:

Pros:

• Explicitness
• Active enforcing of rules

Cons:

• Cluttering the design
• Running with scissors… we like running with scissors, although we probably won’t fall on them

What do you think?

I am having double thoughts.

I am toying with an idea.

One of the pillars of DDD is the pattern of Aggregate Roots and their boundaries. Also the fact that our Repositories should only work against Aggregate Roots and not Entities themselves.

As I like explicitly to enforce my rules I am toying with an idea of a marker interface IAggregateRoot which would not contain ANY elements, just exist.

What I could do then is put a Generics constraint on my Repository like:

IRepository<EntityT, IdentifierT> where EntityT : EntityBase<IdentifierT>, IAggregateRoot

Then all my entities which are Aggregate Roots should be *marked* as one:

Category : Entity<int>, IAggregateRoot

Now… I both like and dislike this, I can’t put my mind what is better yet

Pros:

• Allows us to actively enforce DDD rules and make the users of this framework think about what their roots are and not generalize everything
• Nice explicitness of knowing exactly which entity is a Root and which is not
• In any future gives me a leverage to find out if an Entity is a Root or not if for any reason I need to get this info

Cons:

• Design noise, in it’s sense it doesn’t bring anything concrete to the table, forcing my users to do this one extra step (mark an Entity) and also clutter the design doesn’t sound too thrilling
• What would be a default setup for an entity? Probably that it is an Aggregate root (think code generating your initial model from database or any other resource). Doesn’t this then go against it? Everything is a Root. Also knowing the users, the simplest thing will be to mark them all with IAggregateRoot
  Uhhh… Tough descision.

What do you think?

As you might know I am building my own Repositories for NHibernate as a part of my upcoming “glue” framework.

A part of that implementation are various transformers and default transformation strategies for things like tuple to object transformations (dto) and data reader to object transformations (dto)… the first is used when using projections, the later when calling stored procedures.

I’ve choosen to do this via Linq Expression Trees because I’ve been frankly scared to use the plain DynamicMethod till now, and as Expression trees do generate them in the background it seemed like a great way to do runtime code generation.

Probably in the future I will write some more detailed posts on the implementation itself and more on the reasons, but for starters here are a few links which will help to you give an insight into the power and how LINQ can be used waaaay beyond querying:

http://rogeralsing.com/2008/02/28/linq-expressions-creating-objects/
http://blogs.msdn.com/meek/archive/2008/04/25/using-linq-expressions-to-generate-dynamic-methods.aspx
http://blogs.msdn.com/meek/archive/2008/05/13/using-linq-expressions-to-generate-dynamic-methods-ii.aspx

Enjoy!

As you might know for some time now I’ve been working on my own NHibernate implementation. Largely it is influenced by Ayende’s great Rhino.Commons for NHibernate, but what I like to think is that it took a little bit different direction, and that the details of implementation are what it makes really different (not better or worse… just different).

With this in mind I am working on my own IRepository implementation and have found that it actually has at least 3 reponsibilities it must fullfill:

1. It must be able to Save/Update/Delete/Query Entities
2. It must be able to Query for DTO’s (via projections)
3. It must be able to call Stored procedures

Now, with Ayende’s REALLY great implementation all this is a part of the main IRepository interface, what I’ve decided is that in my implementation they will be split:

• IEntityRepository
• IStoredProcedureRepository
• IProjectionRepository

This allows me to split the responsibilities more accurately over them. Some of the differences:

• IEntityRepository<EntityT> is full featured - it can both query and save/update/delete mapped entities
• IStoredProcedureRepository contains only methods to call stored procedures
• IProjectionRepository also only contains querying possibilities, it can query very similary to Entity repository, difference being that here you define the projections as well and thus tranform the result to a DTO or something else. Also, instead of defining the resulting type on the repository level (IRepository<T>), here you define it on a query level (.Find<T>….)

What do you think of a such idea?

I have to mention that the first two repositories are already made (Entity and Stored procedure), and are fully tested (spec’d out).

Ill describe how the current ones look in a series of upcoming posts, but they do contain some neat things.

Cheers!