Should Domain Entities be exposed as Interfaces or as Plain Objects?

Should Domain Entities be exposed as Interfaces or as Plain Objects ?

The User Interface :

public interface IUser
{
    string FirstName { get; set; }
    string LastName { get; set; }
    开发者_开发知识库string Email { get; set; }
    Role Role { get; set; }
}

The User Implementation (Implemented into LinqToSql Data Access Layer) :

public class User : IUser
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Email { get; set; }
    public Role Role { get; set; }
}

The User Implementation (Implemented into NHibernate Data Access Layer) :

[NHibernate.Mapping.Attributes.Class]
public class User : IUser
{
    [NHibernate.Mapping.Attributes.Property]
    public string FirstName { get; set; }

    [NHibernate.Mapping.Attributes.Property]
    public string LastName { get; set; }

    [NHibernate.Mapping.Attributes.Property]
    public string Email { get; set; }

    [NHibernate.Mapping.Attributes.Property]
    public Role Role { get; set; }
}

this only illustrate some DAL specific implementations, don't have a better sample at this time.

My feeling on this is that domain objects (not domain entities, as that title implies something to do with a database) should not be interfaces unless you have a very compelling reason to believe that you will need to support multiple implementations at some point in the future.

Consider that the domain model is the human model. The business/service/document is, literally, the domain. Most of us are developing software for a single business or purpose. If the domain model changes, it is because the business rules have changed, and therefore the old domain model is no longer valid - there is no reason to keep the old one around, running alongside the new one.

The debate is obviously not black-and-white. You might be developing software that is heavily customized at multiple client sites. You might really need to implement different sets of business rules at the same time, and simultaneously have a genuine need to fit them into a unified architecture. But, in my experience at least, these cases are the exception rather than the rule, and although I am not generally fond of the term, this might be a case where you should be thinking to yourself, YAGNI.

Data access is a common area where you want better abstractions (persistence ignorance). In your example, you have NHibernate attributes on your model class. But adding persistence attributes makes it no longer a true domain class because it introduces a dependency on NHibernate. NHibernate and Fluent NHibernate support mapping POCOs using an external mapping declaration instead of attributes on the data class, and this tends to be the preferred approach when using ORMs such as NHibernate or EF4, because it breaks the dependency between persistence model and domain model.

If these mapping methods weren't supported, and you had to use attributes, then I might indeed suggest using interfaces instead, but ORMs today are more sophisticated than that, using reflection and dynamic proxies and method interception to do most of the heavy lifting, so you don't need to create your own abstractions here.

Some types of objects that you would want to expose as interfaces are:

• Repositories, which are responsible for loading/saving domain objects;
• Plugins/extensions to your program;
• View/presenter models, so that different UIs can be plugged in;
• Abstract data types with many implementations (array, list, dictionary, record set, and data table are all sequences AKA IEnumerable);
• Abstract operations with many possible algorithms (sort, search, compare);
• Communication models (same operations over TCP/IP, named pipes, RS-232);
• Anything platform-specific, if you plan to deploy to more than one (Mac/Windows/*nix).

That's by no means a complete list but it should illuminate the basic principle here, which is that the things best-suited to interface abstractions are the things that:

1. Depend on factors that are likely beyond your control;
2. Are likely to change in the future; and
3. Are horizontal features (used in many parts of the app/architecture).

A domain class will be widely used, but does not fit into either of the first two categories; it is not likely to change, and you have almost complete control over the design. Therefore, unless the classes themselves will be taking on indirect dependencies (which is a situation you should try to avoid whenever possible), I would not go through the extra effort of creating an interface for every class in the domain model.

Interfaces are normally considered to be "contracts" and would therefore define behavior. The other major use is for mocking, so that you could provide domain entities that were mock-ups instead of coming from a specific data source (and having dependencies on that source).

For a simple data transfer object, I can't see a lot of use for defining interfaces, but I'm willing to be proven wrong. I'd go with simple objects for this.

An entity in most cases should not be typed.

An Entity explicitly defines an identity unique to other entities of the same type. An Order entity should already have an identity that is different from all other Order entities in the system. It can also be damaging to an entity's identity if you model it via inheritance.

For example: Say you have a Customer and you implement Customer as AmericanCustomer. Give it all the behavior and state needed to be an american customer (hint: loves shopping!). Then later that same Customer, with the same name, same shopping habits - travels to Japan. Are they still an AmericanCustomer? Do you create a new JapaneseCustomer and copy all the data including the ID of that customer into this new type? That could have consequences..

Does that same customer still love shopping? That may or may not be true for the JapaneseCustomer. Yet now all of a sudden within a single booked flight this Customer is different. Other objects in the system will request that same Customer using its unique id and may end up with a different picture of the object than they expected (an AmericanCustomer). Maybe the Customer is modeled around national origin instead of current location. That could solve some of the problems, but also introduce new ones.

Model your Entities around their identity. Identity isn't just about ID fields. A model is more than that. Entities should have meaningful behavior in the form of business logic, yes, but they aren't services. You should not be worrying about polymorphically dispatching to different behaviors. What is more important is how your system views this Entity via its unique identity. Avoid thinking about entity types. Organize around identities instead.

Plain objects, unless there's a common interface for an implementation that can change. That's what interfaces are for. Value classes like Money or Address don't fall into that category.

Your example interface has no behavior whatsoever beyond getter/setter. That's not what interfaces are for.