2017-01-08 3 views
0

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

Есть ли что-то не так с этим подходом? (Как с точки зрения использования одного и того же контекста и принятия его в качестве параметра в каждом из методов бизнес-логики?)

+0

Вероятно, лучше иметь уровень доступа к данным - которые обрабатывают всю специфичную для БД логику, бизнес-логика не должна знать конкретные данные БД, такие как контекст e.t.c. И время жизни контекста лучше контролировать через контейнеры IoC - как Singleton или One request - один экземпляр контекста. – Vladimir

ответ

0

Я думаю, вам следует реализовать образец проекта и образец структуры работы в вашем проекте.

Репозиторий и блок шаблонов работы предназначены для создания уровня абстракции между уровнем доступа к данным и бизнес-логики заявления

Вы все готовы сделать разделение бизнес-логики уровня и доступа к данным. Теперь вы должны использовать шаблон работы для совместного использования dbcontext.

Единица работа класс координирует работу нескольких хранилищ пути создания единого класса контекста базы данных, разделяемый всеми из них

Подробнее о реализации here.

+0

Вы проверили мой ответ? –

Смежные вопросы