Общий дизайн бизнес-уровня с шаблоном хранилища с помощью c # (как)

Question

Я использую дизайн хранилища с веб-приложениями (хранилище (уровень данных), выставляя модель (объекты) на бизнес-уровень, который затем используется для уровня данных (ui). Объекты или списки объектов передаются между уровнями с помощью этот тип реализации.

Я считаю, что мой бизнес-уровень становится серией классов менеджера, которые имеют общие методы типов GetAll, GetById, Save, Delete. Это очень часто встречается с рядом очень маленьких простых объектов. Это проблемная область или возможности для улучшения (серия небольших бизнес-классов). Я ищу варианты, чтобы избежать целого ряда меньших классов бизнес-менеджера, сопоставляемых с меньшими объектами, которые только получают / сохраняют / удаляют объект.

Более крупные объекты, которые ближе к функциональности приложения, имеют ряд методов в дополнение к методам типа get / save / delete (эти классы менеджера в порядке).

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

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

Идеи о том, как этого добиться? ТНХ

Answer 1

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

Если вы попытаетесь создать общий бизнес-уровень, вам будет сложно включить в него все, что может сделать бизнес-класс. Общий бизнес-уровень станет намного сложнее, чем тот, который у вас есть в настоящее время. Тестирование будет намного сложнее. Добавить новое бизнес-правило тоже будет сложно.

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

Answer 2

Идея хранилища (или дао) состоит в том, чтобы дополнительно абстрагировать проблемы доступа к данным от бизнес-уровня, чтобы упростить внимание этих слоев к «бизнесу» данного домена.

Тем не менее, - это множество распространенных проблем, связанных с сантехникой, которые можно повторно использовать в различных приложениях, некоторые из которых поддаются супертипу на бизнес-уровне. Подумайте о сквозной проблеме, связанной с возможностью извлечения данного субъекта бизнеса по некоторому идентификатору из базы данных, и вы могли бы прийти к выводу, что на самом деле полезно иметь идентификатор недвижимость в бизнес-слое супертипа. Это может быть даже полезно, если субъекты учитывают этот идентификатор при определении равенства. Etc ..

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

Чтобы получить представление о концепции фреймворка для веб-приложения, которое прошло дорожные испытания, ознакомьтесь с SharpArch .

НТН,
Berryl