Entity, Value object or enum representation of objects within domain model

Question

Hi,

I'm trying to build a document management system and despite all the thigns i've read about entities, value objects, how to choose between how to map them etc... i still can't figure out what the "correct" way to do it is. Quite typically in such a scenerio, each document can beong belong to one or more categories, can be viewed by users belonging to one or more roles etc... So the document entity looks something like this:

public class Document
{
    private int _id;
    private string _title;
    private string _brief;
    private DateTime _publicationDate;
    private string _author;
    private string _source;
    private DateTime _activeDate;
    private DateTime _inactiveDate;
    private IList<Category> _categories;
    private IList<Fund> _funds;
    private IList<Role> _roles;
    ...etc
}

The actual domain mondel and business logic for the application is currently pretty thin so the Category, Fund and Role objects do not contain any business logic and are really just means of categorisation, access control etc (in the case of Roles) etc... In the database therefore, i will have 'Role', 'Category', 'Fund' tables for example and then there will be many-to-many mapping tables with 2 columns: e.g. DocumentId and RoleId. My question therefore is:

Should Category, Fund, Role etc.. be represented in the domain as entities e.g.

public class Role
{
 private int _id;
 private string _name;

 public virtual int Id 
 {
  get { return _id; }
  private set { _id = value; }
 }

 public virtual string Name 
 {
  get { return _name; }
  private set { _name = value; }
 }
}

or as value objects or should the Roles for example just be an enum:

public enum Role
{
    AllUsers
    ,ShareHhlders
    ,Registered
    ,Administrator
}

I started off with the entities approach but now i'm trying to create the 'Add document' functionality and UI and questioning whether it's the right approach - In the add document UI the user gets groups of lists of checkboxes and they pick which categories, roles funds etc... the document will belong to. Onec this information is passed to the controller (i'm using ASP.NET MVC) if a checkbox has been selectd then a category/role/fund etc... needs to be created and added to the document object but to do so the Id of the category/role/fund is needed. It means therefore that i have to possibly maintain mapping objects within the application to get the category/role/fund ids for a given category/rle/fund to pass to the constructors of the category/role/fund objects. This really doesn't seem right and hence why i'm asking the question.

I started to try and change the objects to enums but then the enums and category/role/fund/many-to-many-mapping tables used for referential integrity will need to be maintained separetely. This possibly seems to be a requirement to satisfy persistence yet at the database level i think it's necessary to maintain separate category/role/fund tables, mappping tables and foreign key constraints. (Also using NHibernate for ORM mapping and persistence ut should be able to get it to play nice with enumss).

Thanks

Answer 1

When choosing between Entities and Value Objects, it's important to determine if the object has a unique identity with internal parts that can be changed. If the object has a unique identity and supports internal changes, do those changes need to be tracked or persisted to the database? In short, do you need to persist CRUD operations on these objects? If so, you may have an Entity. If not, you may have a Value Object.

My gut says that if you could create enums instead of Entities, then you don't need Entity Objects. I vote to use NHibernate to save foreign keys for referential integrity.