Модель ASP.NET MVC и бизнес-объекты

Question

Я ищу несколько советов о том, как включить бизнес-правила в приложение asp.net mvc и как они связаны с моделью.

Сначала немного предыстории, чтобы мы знали, какие решения являются относительными для этого вопроса. На работе мы используем WinForms, MVP, BusinessObjects, DataAccessObjects и DataTransferObjects. Границы слоев используют DTO для отправки параметров в методы и в качестве возвращаемых типов, или возвращают типы списков.

Прямо сейчас мы добавляем фасадный слой для преобразования DTO в доменные объекты, чтобы пользовательский интерфейс мог работать с ним, поскольку архитектору не нравится, как в настоящее время работает использование DTO в PresentationLayer. Мне удобно все это в теории, кроме того, практично это или нет.

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

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

Я слышал, что люди говорят о LINQ как объектах DataAccessLayer / DataAccessObjects. Если я форсирую все свои запросы через бизнес-объекты, как я привык, я ввожу некоторые странные зависимости. И мой пользовательский интерфейс, и мой BO должны знать о моем DAO.

Что имело бы смысл использовать классы LINQ как настоящий слой DAO, скрыть его за BO и иметь преобразование BO между объектами POCO и LINQ.

Единственное, что меня беспокоит, так это то, что я в порядке с привязкой своего пользовательского интерфейса к классам LINQ, и мне действительно не нужна вся дополнительная работа, я доволен тонким облегченным подходом, как в NerdDinner.

По сути, у меня есть хранилище, которое создается в контроллерах, которые принимают и возвращают объекты LINQ. В моих бизнес-объектах есть статические методы, которые просто берут классы LINQ и выполняют некоторые вычисления, например, применяют определенный налог штатов% или w / e.

Поскольку многие из этих вычислений должны выполняться по результатам хранилища, я думаю объединить их в одну центральную область, например, фасадный слой, но такую, которая просто преобразуется в данные, а не переводится в другие объекты. наборы (DomainObjects <-> DTO).

Должен ли я сделать это, или я должен сказать, что эти бизнес-методы действительно являются частью моей модели и что они должны быть в методах репозитория, которые возвращают объекты?

Answer 1

С точки зрения дизайна я бы разработал это так. Разумеется, для обозначения этой должности вам не обязательно называть свой DAL и BLL .. Репозиторий и ..Service.

Имейте репозитории (или один), где должны происходить ваши обращения к данным / запросы. В идеале он должен содержать запросы (скомпилированные или нет). Лично у меня есть репозиторий для каждого типа данных, чтобы разделять запросы.

Следующим уровнем должен быть уровень вашего бизнеса, который я люблю называть сервисами. Эти классы отвечают за всю логику, касающуюся валидации, подготовительных шагов и всего остального, что необходимо сделать, чтобы получить потребителю услуги необходимую информацию. Как и в приложении ASP.NET MVC, мои сервисы возвращают модели представления, которые затем напрямую передаются в строго типизированные представления. С моими услугами я обычно группирую их логически вместе вместо одного для каждого типа данных.

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