Модульная архитектура и паттерн UnitOfWork в c#?

Здравствуйте. Специально зарегистрировался. Может здесь получу ответ на свой вопрос.

Я пишу программу с использованием модульной архитектуры. То есть, у меня есть "Ядро", а подключаемые модули используют объекты, события и прочее что дает ядро. Ядро разделено по слоям. Один из слоев - "Data Access Layer", сокращенно DAL, который позволяет получить доступ к базе данных. Главная задача данного слоя - абстрагироваться от источника данных, так как мне нужно поддерживать и mysql и postgresql. Для доступа данных я решил использовать паттерн UnitOfWork, так как мне необходимо контролировать транзакции. Пример данного паттерна можно найти, например, здесь https://metanit.com/sharp/mvc5/23.3.php
В данном примере всего 2 сущности (таблицы). У меня же 15 таблиц и поэтому мой UnitOfWork имеет 15 свойств.
Все отлично - я не пишу повторяющийся код, могу легко сменить базу данных.

Как я сказал раннее у меня модульная архитектура. При подключении модуля ему передается Экземпляр класса UnitOfWork и , соответственно, модуль может пользоваться всеми полями (репозиториями таблиц) и обращаться к их свойствам.

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

Инжектить отдельно "Таблицы" в методы - не очень хорошая идея - в одном модуле может использоваться до 12 таблиц.

Как сделать так, чтобы все это было расширяемо и независимо? В мире php, например Laravel многие просто создают экземпляры модели внутри контроллеров - но это как фу.

Кстати, если что я пишу под десктоп.
  • Вопрос задан
  • 657 просмотров
Пригласить эксперта
Ответы на вопрос 1
@EvgeniiR
https://github.com/EvgeniiR
При подключении модуля ему передается Экземпляр класса UnitOfWork и , соответственно, модуль может пользоваться всеми полями (репозиториями таблиц) и обращаться к их свойствам.

Это явное пренебрежение и нарушение Interface Segregation Principle. Не нужно так делать.
Репозиторий и UoW не противоречат друг другу. Даёте сервису репозиторий, а под капотом у него уже могут быть любые инструменты, в т.ч. UoW.

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

Модуль меняет схему БД? Думаю стоит первоначально попробовать пересмотреть его логику работы.

Как правильно поступить, чтобы Ядро не подстраивалось под модули, а модули подстраивались под ядро. И именно модули использовали средства ядра для комфортной работы с базой.

В ядре лежит реализация работы с базой, или лишь объявления необходимых интерфейсов?
Для реализаций то есть отдельный Data Access Level.
По хорошему ваш слой с бизнес логикой должен объявлять нужные интерфесы для работы с хранилищем, а слой доступа к хранилищу эти интерфейсы реализовывать. В верхний слой нужная реализация попадает, соответственно, через какой-либо механизм инверсии зависимостей(DI)

Небольшое примечание

Один из слоев - "Data Access Layer", сокращенно DAL, который позволяет получить доступ к базе данных. Главная задача данного слоя - абстрагироваться от источника данных, так как мне нужно поддерживать и mysql и postgresql

Задача данного слоя - абстрагировать ядро от хранилища, а он уже может использовать любые фичи нужных БД как ему нужно.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы