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!

Had a funny problem today. I’ve written a spec (tests) for a code that should have iterated over a collection of items and with some conditions do a yield return for each of them.

In it’s form, its a very simple piece of code, but somehow I could not for the light of me get the spec (test) to pass. It always seemed that the code didn’t even execute… I kept thinking to myself, WTF? This code is simple, and it does what it needs to!? Why doesn’t it pass? (as you can imagine I got a bit frustrated).

Then I remembered one *small* bit… yield return coupled with IEnumerable provides the deferred execution for my code, so this example:

When called like this in my spec (test):

Actually does nothing at all, so my specs would fail… it was really frustrating.

What can be done?

Actually, three things:

So:

s1) We are enumerating like we are expected to. This will execute the functionality

s2) We are manually assembling the enumerator and asking him to call our functionality

s3) We are feeding the deferred execution functionality to a new List which internally then executes it

I personally prefer and use option 3 now.

Hope this helps someone, it sure would me if I’ve remembered it out earlier.

Cheers!

So, quite a simple rule… someone likes it, someone doesn’t.

I’ve seen over and over these kinds of examples:

This is probably to simple of an example, but should prove a point.

To some extended, this code (because it’s stupid and simple) could be converted to:

But what I would advise you is that instead you fail early with the logic instead of branching and complicating the code like above (keep in mind once more that that above is too simple of an example)

How would you fail early in this case?

What do you think? How do you do it?

Cheers!