Справка по архитектуре ASP.NET MVC / DDD - PullRequest
1 голос
/ 09 мая 2009

Я создаю веб-приложение с использованием ASP.NET MVC и пытаюсь использовать дизайн, управляемый доменом. У меня есть вопрос архитектуры.

У меня есть таблица WebControl для хранения ключей и значений для списков, чтобы их можно было редактировать. Я включил это в свою бизнес-модель, но это приводит к большому количеству избыточного кода, и я не уверен, что он там есть. Например, в моем классе Request у меня есть свойство NeedType. Поскольку это происходит из списка, я создал класс NeedType для предоставления значений для переключателей. Я показываю здесь только один пример, но форма будет иметь приблизительно дюжину списков, которые должны поступить из базы данных.

[править, чтобы уточнить вопрос] Какой лучший способ сделать это? Эти объекты списка действительно являются частью моего домена или они существуют только для пользовательского интерфейса? Если они не являются частью домена, то они не входят в мой основной проект, поэтому куда они идут?

public class Request : DomainObject
{
   public virtual int RequestId { get; set; }
   public virtual DateTime SubmissionDate { get; set; }
   public virtual string NeedType { get; set; }
   public virtual string NeedDescription { get; set; }
   // etc.
}

public class NeedType : DomainObject
{
    public virtual int NeedTypeId { get; set; }
    public virtual string NeedTypeCode { get; set; }
    public virtual string NeedTypeName { get; set; }
    public virtual int DisplayOrder { get; set; }
    public virtual bool Active { get; set; }
}

public class RequestController : Controller
{
    private readonly IRequestRepository repository;

    public RequestController()
    {
        repository = new RequestRepository(new HybridSessionBuilder());
    }

    public RequestController(IRequestRepository repository)
    {
        this.repository = repository;
    }

    public ViewResult Index(RequestForm form)
    {
        ViewData.Add("NeedTypes", GetNeedTypes());
        if (form == null)
        {
            form = new RequestForm();
            form.BindTo(repository.GetById(125));
        }
    }

    private NeedType[] GetNeedTypes()
    {
        INeedTypeRepository repo = new NeedTypeRepository(new HybridSessionBuilder());
        return repo.GetAll();
    }
}

Ответы [ 3 ]

3 голосов
/ 09 мая 2009

Создайте отдельную модель представления с нужными вам данными. Модель в M MVC не совпадает с моделью предметной области. MVC viewmodels - это тупые DTO без поведения, только со свойствами. Модель предметной области имеет максимально возможное поведение. Доменная модель с get; set; Только свойства считается анти-паттерном, называемым «моделью анемичной области». Есть 2 места, где большинство людей размещают модели представления: на веб-уровне, рядом с представлениями и контроллерами или на уровне службы приложений.

Edit:

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

Я думаю, что было бы также неплохо последовать совету Тодда Смита относительно объекта стоимости. Когда во время выполнения пользователи могут добавлять или редактировать NeedY-типы, Needtype должен быть объектом. Когда NeedYTIP-коды жестко запрограммированы и изменяются только в новых выпусках проекта, NeedType должен быть объектом-значением, а список NeedYPY-типов может заполняться чем-то вроде NeedType.GetAll () и храниться в базе данных путем добавления столбца в таблицу запросов. вместо отдельной таблицы нужного типа.

1 голос
/ 09 мая 2009

Ваш NeedType для меня выглядит как объект значения. Если это данные только для чтения, то они должны рассматриваться как объект значения в архитектуре DDD и являются частью вашего домена.

Многие люди сталкиваются с проблемой «все так много избыточности» при работе с DDD, так как вы больше не используете старый подход Database -> DataTable -> UI.

1 голос
/ 09 мая 2009

Если это из списка, то держу пари, что это внешний ключ. При проектировании модели вашего домена вообще не думайте о своем интерфейсе. Это просто случай, когда NeedType является внешним ключом. Замените строку NeedType ссылкой на фактический объект NeedType. В вашей базе данных это будет ссылка на идентификатор.

Когда вы создаете свой список вариантов NeedType, вам просто нужно вытянуть каждый NeedType. Возможно, было бы неплохо сохранить его в кэше, если он не сильно изменится.

...