Business entities / value objects framework with DbC support

Question

The thing I think I spend most time on when building my business models is the validation of business entities and making sure the entity objects and their relationships maintains good integrity. My dream for a good entity/value object framework would help me create reusable entities/value objects and easily create constraints and rules for relationships as you would in a db but since I feel this really is business rules they belong in the model and should be totally independent of the database.

It should be easy to define that the Name property of a Person object should be required and that the Email property should be required and match a certain regex and that these rules should be easily reusable f.ex. in validating input in my web app.

I have absolutely most experience with Linq to sql and even though it certainly is nice to work with it has limit by not supporting value objects and others. My question is would Entity framework or NHibernate be more suiting or are there other technologies that fit my needs better?

Answer 1

There was a small book I read last year by Steve Sanderson himself that briefed me on DDD concepts. Even though the book was on ASP.NET MVC as a preview, he really focused on the "M" in MVC as a true and pure Domain Model - using almost 1/2 the book on modeling approaches (which I very much enjoyed). One thing he approached was using Value Objects in the context of Aggregate Roots (obviously). But, he also showed how to use Linq to represent the entities, as well as the Value Objects.

The point is, he noted the limitation of Linq that it must have an identity on every object, including Value Objects. He acknowledged it broke the pure domain model approach; but, it was the only way to get it to work with Linq-to-SQL.

His work-around was to give your Value Object an Identity; but, make that identity internal so it is not exposed outside of your model. This will allow you to link and share your objects using Linq in your repositories; while not exposing it to the client layers - so, it is as though they are Value Objects exclusively.

The Entity Framework I believe suffers from the same requirement.

A C# example is below.

public class MyEntity
{
  [Column(IsPrimaryKey = true
    , IsDbGenerated = true
    , AutoSync = AutoSync.OnInsert)]
  public int EntityID { get; set; }

  [Column(CanBeNull = false)]
  public string EntityProperty
  {
    get
    {
      // insert business rules here, if need be
    }
    set;
  }
}

public class MyValueObjectForMyEntity
{
  // make your identity internal
  [Column(IsPrimaryKey = true
    , IsDbGenerated = true
    , AutoSync = AutoSync.OnInsert)]
  internal int ValueObjectID { get; set; }

  // everything else public
  [Column(CanBeNull = false)]
  public string MyProperty { get; set; }
}

Answer 2

Even though it appears you're on the .Net side of the world, I'd highly recommend Eric Evans' book "Domain Driven Design". (There's actually more UML than Java, and the ideas should port.)

It's a patterns book, but he proposes a number of design strategies that argue for sticking all of the object rules logic ("invariants") into a centralized domain; he then goes on to riff about a number of commonly-understood patterns and makes issues like yours seem more tractable. Well, if not tractable, at least more manageable in the longer term.