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

Question

[netmaster]

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

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

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

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

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

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

Кстати, если что я пишу под десктоп.

Comments

[Василий]

Что вам мешает создать метод CreateTable, в который вы сможете передавать определенный вами же кастомный объект описывающий таблицу?

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

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

[netmaster]

CreateTable это только вершина айсберга. Мне нужны и другие специфические методы.
Ну создал я таблицу. А к ней как обращаться? Проблема не в одном методе, а в том, чтобы модуль имел возможность делать все что он хочет и не быть ограниченным.

Answer 1

[Евгений Ромашкан]

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

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

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

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

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

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

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

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

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

Comments

[netmaster]

Это явное пренебрежение и нарушение Open-Close Principle. Не нужно так делать.

Не вижу нарушения, так как ядро не должно знать, какой сервис передавать модулю. Ядро не должно подстраиваться под модули.

Хорошо. Например я вынесу DAL из ядра и сделаю его отдельным слоем, на который остальные могут ссылаться.

Даёте сервису репозиторий, а под капотом у него уже могут быть любые инструменты, в т.ч. UoW.

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

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

Да, модуль должен иметь возможность менять структуру, как он пожелает. Например, модуль Рейтинга песни. Где он будет хранить данные о рейтинге? Или изначально создать в базе данных эту таблицу? А вдруг она вообще может не понадобиться, так как этот модуль будет не нужен.

Главное для меня - чтобы модуль имел свой DAL, который расширяет основной, дополняет его необходимыми только данному модулю свойствами.

[Евгений Ромашкан]

netmaster,

Не вижу нарушения, так как ядро не должно знать, какой сервис передавать модулю. Ядро не должно подстраиваться под модули.

Хорошо. Например я вынесу DAL из ядра и сделаю его отдельным слоем, на который остальные могут ссылаться.

Нарушение OCP это давать каждому модулю огромного монстра в виде UoW, 90% функционала которого модулю не нужно, да и вообще - а где абстракция то? Почему модули знают про Unit Of Work? Работа с UoW это слой DAL, ни как не любой другой.

Или изначально создать в базе данных эту таблицу?

Конечно изначально, миграцией

А вдруг она вообще может не понадобиться, так как этот модуль будет не нужен.

Я думал такие вещи решаются до разработки модуля,, есть модуль - есть таблица. Удалили модуль - удалили таблицу(ещё одной миграцией)

Главное для меня - чтобы модуль имел свой DAL, который расширяет основной, дополняет его необходимыми только данному модулю свойствами.

Объявите нужный интерфейс для работы с хранилищем и инжектите его в модуль, на каком этапе проблема то тогда?

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