域模型中的实体、值对象或对象的枚举表示
我正在尝试构建一个文档管理系统,尽管我读过有关实体、值对象、如何在如何映射它们等之间进行选择的所有内容......我仍然无法弄清楚什么是“正确”的方式这样做是。 在这样的场景中非常典型的是,每个文档可以属于一个或多个类别,可以由属于一个或多个角色的用户查看等等......因此文档实体看起来像这样:
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
}
实际的域 mondel 和业务逻辑该应用程序目前非常薄,因此类别、基金和角色对象不包含任何业务逻辑,实际上只是分类、访问控制等(在角色的情况下)等的手段...因此,在数据库中,我将有例如“角色”、“类别”、“基金”表,然后将存在具有 2 列的多对多映射表:例如 DocumentId 和 RoleId。 因此,我的问题是:
类别、基金、角色等是否应该在域中表示为实体,例如
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; }
}
}
或值对象,或者角色应该只是一个枚举:
public enum Role
{
AllUsers
,ShareHhlders
,Registered
,Administrator
}
我开始使用实体方法,但现在我正在尝试创建“添加文档”功能和 UI 并质疑这是否是正确的方法 - 在添加文档 UI 中,用户获得复选框列表组,然后选择文档所属的类别、角色资金等。 Onec 如果选择了复选框,则此信息将传递到控制器(我正在使用 ASP.NET MVC),然后需要创建类别/角色/基金等...并将其添加到文档对象中,但要做到这一点需要类别/角色/基金的 ID。 因此,这意味着我必须在应用程序中维护映射对象,以获取给定类别/角色/基金的类别/角色/基金 ID,以传递给类别/角色/基金对象的构造函数。 这看起来确实不对,因此我才问这个问题。
我开始尝试将对象更改为枚举,但随后需要单独维护用于引用完整性的枚举和类别/角色/基金/多对多映射表。 这似乎是满足持久性的要求,但在数据库级别,我认为有必要维护单独的类别/角色/基金表、映射表和外键约束。 (还使用NHibernate进行ORM映射和持久化ut应该能够让它与enumss很好地配合)。
谢谢
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
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
在实体和值对象之间进行选择时,确定对象是否具有唯一标识以及可以更改的内部部分非常重要。 如果对象具有唯一标识并支持内部更改,是否需要跟踪这些更改或将这些更改保存到数据库? 简而言之,您是否需要对这些对象持久化 CRUD 操作? 如果是这样,您可能有一个实体。 如果没有,您可能有一个值对象。
我的直觉告诉我,如果您可以创建枚举而不是实体,那么您就不需要实体对象。 我投票支持使用 NHibernate 来保存外键以实现引用完整性。
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.