Бизнес-логика ASP.NET MVC в модели домена против уровня обслуживания

Во-первых, ваша папка Model в вашем проекте Asp.Net MVC должна использоваться для ViewModels. Это модели, которые ваши контроллеры отправляют в ваши представления. Они должны быть сильно оптимизированы для представления, то есть только свойства, необходимые для представления, и ничего больше.

То, о чем вы говорите, модели предметной области, такие же, как бизнес-модели, и принадлежат вашему бизнес-уровню. Папка Model в вашем проекте Asp.Net MVC - это модели для вашего уровня пользовательского интерфейса.

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

Эти бизнес-модели / модели предметной области обычно являются POCO, но это не обязательно. Вот как я иногда строю свои бизнес-модели:

public class BusinessObject
{
    private DataObject _dataObject;

    public BusinessObject(DataObject dataObject)
    {
        _dataObject = dataObject;
    }

    public int BusinessId
    {
        get {return _dataObject.Id;}
        set {_dataObject.Id = value;}
    }

    public string Name
    {
        get {return _dataObject.Description;}
        set {_dataObject.Description = value;}
    }
}

Я предпочитаю НЕ использовать бизнес-логику в моделях предметной области. Я сохраняю свои модели предметной области обычно как POCO, чтобы представить свои таблицы / схему БД.

Удержание бизнес-логики от моделей предметной области позволит мне повторно использовать мою модель предметной области с другим проектом.

Вы можете рассмотреть промежуточный уровень между вашими контроллерами и уровнем доступа к данным / уровнем репозитория, чтобы справиться с этим. Я бы назвал это уровнем обслуживания.

Я знаю, что на это уже был дан ответ, но я делю модели на 3 группы.

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

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

PersistenceModels - это модели вашего механизма сохранения состояния. Для большинства из нас это означает моделирование таблицы базы данных, но это также может быть сложный документ nosql или данные json (или любые другие), возвращаемые из запроса api. Их ответственность заключается в том, чтобы справиться с обыденной схемой того, какую форму принимают ваши внешние данные.

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

Модели предметной области должны иметь возможность выполнять свою работу самостоятельно и предоставлять свойства и методы, которые представляют их состояние и функции. Они действуют как корни (совокупные корни) иерархии информации, которая требуется моделям для функционирования. Они остаются скрытыми, доступными только для сервисов.

Сервисы предоставляют функциональность бизнеса / домена внешнему миру (веб-сервисы, пользовательский интерфейс и т. Д.) В виде набора API-интерфейсов, следующих шаблону сообщения (запросы / ответы), путем извлечения моделей из репозиториев, которые инкапсулируют уровень доступа к данным, с последующим вызовом методов / бизнеса функции на моделях и, наконец, сохранение их обратно в репозитории.

Иногда кажется, что сервисы повторяют методы бизнес-объектов, но во времени и на практике это не то, что происходит на самом деле.

В реальном дизайне, ориентированном на предметную область, вам нужно как минимум 3 набора объектов. Бизнес-объекты, репозитории бизнес-объектов и сервисов.

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

Логика управления потоком приложений принадлежит контроллеру.

Логика доступа к данным принадлежит репозиторию.

Логика проверки относится к уровню обслуживания.

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

Уровень сервиса содержит бизнес-логику проверки.

Например, уровень обслуживания продукта имеет метод CreateProduct ().

Метод CreateProduct () вызывает метод ValidateProduct () для проверки нового продукта перед передачей продукта в репозиторий продуктов.

Источник: http://www.asp.net/mvc/overview/older-versions-1/models-data/validating-with-a-service-layer-cs