Entity, Value value или перечислимое представление объектов в доменной модели - PullRequest
1 голос
/ 21 июня 2009

Я пытаюсь построить систему управления документами и, несмотря на все трюки, которые я прочитал о сущностях, объектах значений, о том, как выбирать между тем, как их отображать и т. Д., Я все еще не могу понять, что " Правильный «способ сделать это есть. Обычно в таком сценарии каждый документ может принадлежать к одной или нескольким категориям, его могут просматривать пользователи, принадлежащие к одной или нескольким ролям и т. Д. Таким образом, сущность документа выглядит примерно так:

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
}

Реальная доменная логика и бизнес-логика для приложения в настоящее время довольно тонкие, поэтому объекты Category, Fund и Role не содержат никакой бизнес-логики и на самом деле являются просто средствами категоризации, контроля доступа и т. Д. (В случае ролей) и т. Д. ... Следовательно, в базе данных у меня будут таблицы «Роль», «Категория», «Фонд», а затем будут таблицы сопоставления «многие ко многим» с двумя столбцами: например, 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
}

Я начал с подхода с использованием сущностей, но сейчас я пытаюсь создать функциональность и пользовательский интерфейс «Добавить документ» и спрашиваю, правильный ли это подход. В пользовательском интерфейсе добавления документа пользователь получает группы списков флажков и выбирает к каким категориям, фондам ролей и т. д ... документ будет принадлежать. Однажды эта информация передается контроллеру (я использую ASP.NET MVC), если установлен флажок, необходимо создать категорию / роль / фонд и т. Д. И добавить их в объект документа, но для этого необходимо Требуется идентификатор категории / роли / фонда. Следовательно, это означает, что я должен поддерживать объекты отображения в приложении, чтобы получить идентификаторы категории / роли / фонда для данной категории / роли / фонда, которые необходимо передать конструкторам объектов категории / роли / фонда. Это действительно кажется неправильным, и поэтому я задаю вопрос.

Я начал пытаться изменить объекты на перечисления, но тогда таблицы и перечисления и таблицы категорий / ролей / фондов / многих-ко-многим, используемые для ссылочной целостности, необходимо будет поддерживать отдельно. Возможно, это является требованием для обеспечения устойчивости, но на уровне базы данных я считаю необходимым поддерживать отдельные таблицы категорий / ролей / фондов, таблицы сопоставления и ограничения внешнего ключа. (Также используя NHibernate для ORM-картографирования и персистентности, у вас должна получиться, чтобы он хорошо играл с enumss).

Спасибо

1 Ответ

2 голосов
/ 21 июня 2009

При выборе между сущностями и объектами значений важно определить, имеет ли объект уникальную идентичность с внутренними частями, которые можно изменить. Если объект имеет уникальный идентификатор и поддерживает внутренние изменения, нужно ли отслеживать эти изменения или сохранять их в базе данных? Короче говоря, вам нужно сохранить CRUD-операции на этих объектах? Если это так, у вас может быть сущность. Если нет, возможно, у вас есть объект значения.

Моя интуиция говорит, что если бы вы могли создавать перечисления вместо сущностей, то вам не нужны объекты сущностей. Я голосую за использование NHibernate для сохранения внешних ключей для ссылочной целостности.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...