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

Question

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

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

У вас должен быть один репозиторий на 'модуль' или 'root-aggregate'.Это то, что определенный репозиторий может охватывать гораздо больше, чем только одна таблица. Мы сгруппировали связанные таблицы в один репозиторий. Примерами являются то, что у нас есть RelationRepository поверх других таблиц, таких как Person, Company и OrderRepository, поверх таблиц Orders, OrderLines, FlightRepository поверх таблиц, чтобы хранить все данные для рейсов и т. Д. Это репозиционный шаблон как вы все равно должны использовать его в соответствии с проектом, управляемым доменом.