Polluting domain types by implementing infrastructure-related interfaces

Question

Hi all,

Did about 30 minutes worth of searching, found lots of relevant info, but none that addresses this particular concern, hope I'm not repeating a common question.

I would like to know what the general consensus is in regard to implementing infrastructure-related interfaces in domain types. Everything I've read about DDD leads me to believe that this is to be avoided, as this understandably detracts from the conciseness of the model.

I am, however, at a point where I'm uncertain as to how to work around this. Specifically, I've got a domain type that would be perfectly fine to use in my presentation layer, except that I'd like to display an instance of it in a control that requires it implements IComparable. I would rather not 'pollute' my type with an implementation of this interface.

I think (perhaps naively) my options are:

1. Use a Data Transfer Object (DTO), have it implement the interface, and use an instance of that in my presentation layer.
2. I'm vaguely familiar with the fundamentals of AOP - perhaps there's a suitable technique in this realm?
3. Perhaps related to option 2 - code 'weaving'? I know very little of why/when to consider this, but am I bumping up against it now?
4. Bite the bullet, and implement the bit of code that it takes to satisfy the contract.
5. Some voodoo-magic I've never even heard of?

If anybody cares to recommend 2, 3, or 5 - could you point me in the direction of some reading material that might help get me started?

Thx in advance.

Answer 1

1. This will work, and should be fine.

2-4. These are really the same option. The difference is in how you implement the code to satisfy the contract. Code weaving and AOP are still "polluting" your object, but they're doing the work for you in a semi-automatic way (ie: you just put an attribute on your object, and it implements it post-compile). The final result is the same, though, whether you implement the object or use AOP/code gen.

1. My suggestion below:

Most of the time, anything that requires IComparable<T> also provides an option to pass an IComparer<T>. If your control does, this would let you implement the comparing logic external to your data objects, and just pass it in as well. I would investigate this as an option first.

Otherwise, my suggestion would be to just implement IComparable<T> directly in the object. If you don't want to "pollute" the API, just implement it explicitly.

Answer 2

implement an intermediate "View-Model" class:

• the View part knows how to talk to the user-interface (databinding, IComparable, et al)
• it holds a reference to the Model (domain) object
• it exposes the properties of the Model object (and relays change notifications if necessary)