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

Question

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

Думаю, вы правы в том, что не помещаете синтаксический анализ этой строки в слой SVC, так как это может нарушить SRP.