I don't have a specific link for this one, but I remember a conversation I had (on Twitter of course!) with Nate Kohari, author of Ninject, and Justin Etheredge about the attribute requirements specified by Inversion of Control containers on domain entities. Ninject, for example, requires attributes on properties to do property injection. During the conversation, I stated that I prefer to keep my domain entities clean, and not have them decorated with attributes. And Ninject supports that, so that's how I was using it.

But as I thought about it, I realized I was being hypocritical. Here's a sample property generated from the NuSoft Framework.

   1:  [DatabaseColumn()]

   2:  [TypeConverter(typeof(MinToEmptyTypeConverter))]

   3:  [DataObjectField(true, false, false)]

   4:  public string Username

   5:  {

   6:     [DebuggerStepThrough()]

   7:     get { return this._username; }

   8:     set { this._username = value; }

   9:  }

One property has four attributes!

Now the question is, which is the Right Way to do things? Are you OK with attributes in your domain entities, or would you rather have them be pure? Does it matter the direction of the attribute's intent? I.e., is it more acceptable to have an attribute for the data layer (which is underneath the domain layer) than to have an attribute for an IoC container (which sits on top of the domain layer)? Or vise versa?

And yes, I realize there isn't a Right Way that fits all cases. Anyway, I'm not sure where I stand now. I thought I liked clean entities, but I also see value in having the attributes as well.

Tags: Ninject | Attributes | Development