Шаблон репозитория и тип данных возвращены

Question

Шаблон репозитория и тип данных возвращены

2

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

CSharpAtl 05 июнь 2009, в 20:36

Источник

Теги:

c#

.net

repository-pattern

ddd-repositories

4 ответа

3

Репозиторий должен обязательно вернуть бизнес-объект.

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

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

Joseph 05 июнь 2009, в 17:04

0

Да, я не думал о том, чтобы репозиторий говорил с сервисным уровнем, а просто о том, что сервис выполняет синтаксический анализ, но я собираюсь сделать так, чтобы репо выполнило синтаксический анализ (или через переданный интерфейс) и вернул объект модели. Спасибо +1
CSharpAtl 05 июнь 2009, в 19:03

0

Мой предпочтительный вариант не должен хранить данные в строке с фиксированной шириной в первую очередь.:)

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

Если вы оставите его в репозитории, вы можете создать специальный класс для управления этой строкой и передать его (как интерфейс) в репозиторий. Таким образом, вы можете unit test код обработки строк как сумасшедший (и повторно использовать его там, где это необходимо) и оставить свой репозиторий простым.

Talljoe 05 июнь 2009, в 17:26

0

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

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

Josh E 05 июнь 2009, в 17:25

Ещё вопросы

Да, я не думал о том, чтобы репозиторий говорил с сервисным уровнем, а просто о том, что сервис выполняет синтаксический анализ, но я собираюсь сделать так, чтобы репо выполнило синтаксический анализ (или через переданный интерфейс) и вернул объект модели. Спасибо +1

jlembke · Accepted Answer · 2009-06-05T15-33-00.000Z

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

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

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

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