Должна ли служба зависеть от многих хранилищ или разрушать их?

Question

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

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

Не лучше ли было бы разбить этот единственный сервис на несколько небольших сервисов? Это поместило бы больше кода на уровень пользовательского интерфейса, но сделало бы сервисы меньшими и более тестируемыми.

Answer 1

У меня не было бы класса репозитория для таблицы / класса.

У вас должен быть один репозиторий на каждый «модуль» или «корневой агрегат». То есть определенный репозиторий может охватывать гораздо больше, чем просто одну таблицу. Мы сгруппировали связанные таблицы в один репозиторий. Например, у нас есть RelationRepository поверх разных таблиц, таких как Person, Company и OrderRepository поверх таблиц Orders, OrderLines, FlightRepository поверх таблиц для хранения всех данных для рейсов и т. Д. Это шаблон хранилища, так как вы все равно должны использовать его в соответствии с дизайном, управляемым доменом.

Answer 2

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

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

Answer 3

Думаю, я бы сосредоточился на двух предложениях в среднем абзаце:

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

Во-вторых, почему так сложно настроить фальшивые репозитории в вашей тестовой системе? Не могли бы вы сделать это проще? Я часто использую конструктор для установки похожих, но не идентичных структур данных для использования в тестах. Затем вы получите тесты, которые читают «при обычной настройке , за исключением разницы X , проверьте, что происходит Y».

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

Answer 4

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