Comments on: Entity interface anti-pattern

By: Kyle Szklenski

Kyle Szklenski — Thu, 14 May 2009 13:26:56 +0000

I’ve seen numerous places where an interface was used to provide only properties. It made me sick. I think doing that basically has the interface implying implementation, or what data is allowed to be stored in the implementing classes. What would the difference be if those weren’t properties at all, but were allowed to be data members directly? Sometimes those properties return abstract types, which is better, but it still seems largely pointless to me to have an interface with just properties. Good post.

By: John Polling

John Polling — Mon, 11 May 2009 09:58:48 +0000

Having read your article has made me realise I need to be more careful about the behaviours I’m putting into my service layers that should probably be going into my entities.

By: chrissie1

chrissie1 — Mon, 11 May 2009 08:55:35 +0000

There is a use for interfaces on domain entities, and I think I heard this of Udi Dahan. When you use the tell don’t ask principle on your entites you won’t have a need for properites but that makes for difficult unittesting. So you can have an interface that only has methods and an implementation that also has properties for unittesting or peristence. Then you just pass the interface around and don’t need to worry about people using the properties.

So there can be a reason for interfaces on entites, ok they are not bu still 1:1.

By: James Gregory

James Gregory — Mon, 11 May 2009 08:25:04 +0000

To those who mentioned the anemic domain, you are of course right; I should have been a little clearer on what I meant by having no behavior.

Entities should have behavior that concerns their own state, and anything directly related to them. Jak’s examples fall into that category. They should not know how to save themselves (unless you’re doing AR), log themselves, query themselves, etc… That’s the kind of behavior I was referring to (albeit not very clearly).

Again, Jak’s examples are exactly what I’m not talking about in this post. Those are a good example of interfaces on entities. They are a subset of behavior, which can be applied to multiple entities; not a single interface per entity.

By: Jak Charlton

Jak Charlton — Mon, 11 May 2009 07:56:43 +0000

An anemic domain is an anti-pattern ….

1-1 interfaces to classes is also an anti pattern …

The first is the worst of the two

Entities should and must include behaviour – otherwise they are DTOs not entities (in any real usage of the word)

To solve the second anti pattern – interfaces should be use case based around entities, or preferably around aggregate roots (to use the DDD term).

SO instead of
Customer : ICustomer

you have
Customer: IUpgradeableToPreferred, ICanPlaceAnOrder

etc etc …. which combines ISP, with avoiding the interface anti-pattern, and putting your domain logic on your entities to avoid an anemic model

By: Justice

Justice — Mon, 11 May 2009 01:43:46 +0000

Anonymous is right, in the sense that you assume that your domain model entities should have no behavior. But the opposite is true. Your domain model entities should be rich with behavior, and should certainly be tested. However, all non-pure concerns (persistence, logging, etc) should be done outside of the domain model: persistence with an ORM like NHibernate and logging with interceptors. Therefore, there is no need to have your domain model entities be interfaces: your domain model is perfectly testable on its own, as fully concrete and fully implemented behavior-rich classes.

By: Germán Schuager

Germán Schuager — Sun, 10 May 2009 22:49:16 +0000

Fabio, I can see some uses for something like ICarInfo, but what do you gain with IVehicle or ICar?

By: Anonymous

Anonymous — Sun, 10 May 2009 22:30:43 +0000

“Entities are purely data structures, and as there’s no variance in how you can implement a structure, there’s nothing that can be gained from abstracting it.” Speaking of anti-patterns: http://martinfowler.com/bliki/AnemicDomainModel.html

By: Fabio Maulo

Fabio Maulo — Sun, 10 May 2009 22:09:41 +0000

class Vehicle: IVehicle, IVehicleInfo
class Car: Veicle, ICar, ICarInfo
class CarDTO : ICarInfo
….
ShowCars(IEnumerable cars)

Which will be the implementation passed to ShowCars method ?