Доменные классы/объекты с чистым уровнем устойчивости (DAOs, Factoryories, ...)

Question

Что такое чистый способ объединить объекты домена с объектами уровня без Поддержка ORM-фреймворка?

У меня есть Доменные классы/сущности zcl_document и zcl_document_request (1: n). Я хочу, чтобы классы домена содержали только основную логику домена, no инфраструктура, нет «помощников», нет механизмов настойчивости/загрузки.

Будучи в ABAP, я определил «чистый» structureszs_document и zs_docreq для каждого объекта, которые подвергаются как общественному-только для чтения data атрибута (мы в ABAP в конце концов). Таким образом, мне не нужна куча геттеров на сущности и минимизация методов для основной логики домена.

Чтобы получить тонкий Постоянство-слой, я определил DAO -интерфейс, который read, save и find_by_x для каждой базы данных таблицы (в том числе дополнительного текста стола и прочее). Их возвращаемым типом всегда является structure или таблица структуры, не объект объекта. Поэтому у меня есть тестовый/заменяемый тонкий слой persistence. Этот уровень настойчивости теперь также можно использовать в отчетах, которые обрабатывают массовые данные, потому что я не вынужден создавать объекты-экземпляры или графики объектов, я могу прибегнуть к работе с (надеюсь, чистыми) структурами.

Чтобы создать экземпляр объекта, обычно каждый объект имеет общедоступный статический метод create (фабричный), который принимает «чистую» структуру, проверяет и создает свой экземпляр. Объектам, которые имеют фундаментальные ассоциации с другими объектами, сложнее create, так как также необходимо создать зависимые объекты. Эти лица получают свои zcl_document_request_manager (несут именование). Менеджер знает, как create (заводская) и save объект, включая все связанные объекты. Следовательно, это также friend объектов.

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

Работа с ним будет выглядеть следующим образом:

create object lo_docreq_mng exporting dao, dao, dao, dao,... 

lt_docreq = docreq_dao->find_by_x(...) // table of structure 

foreach lt_docreq as ls_docreq // structure 
    lo_docreq = lo_docreq_mng=>create(ls_docreq) // factory => instance 

    lo_doc = lo_docreq->get_document() // was created with document-instance 

    lo_docreq->do_something_mutating().  
    lo_docreq_mng->save(lo_docreq) // save including dependent objects 

ли это возможно, или есть какой-то запах? Любой комментарий оценен.

Answer 1

Мне нравится ваш подход. Я хотел бы изменить некоторые вещи:

1), чтобы пользователь домена объектов очистить от строительного кода, вы могли бы обеспечить docreq-класс, который возвращает список сущностей вместо структур:

lt_doc = doc_qry->find_by_x(...) // table of entities 
foreach lt_doc as lo_doc 
    lo_doc->do_something_mutating().  
    lo_doc_mng->save(lo_doc) // save including dependent objects 

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

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

3) Я бы не пошел на статические методы. Во-первых, их легко реализовать, но для более поздних изменений они могут стать адскими

и относительно обсуждения использования ORM: я бы не смешивал постоянство и логику домена, так как это уменьшает возможности тестирования. Использование ABAP-ORM исключительно в качестве слоя стойкости не имеет большой пользы. Зачем переносить данные в класс и использовать его как простую abap-структуру (в большинстве случаев)? С другой стороны, ему не хватает хорошего DQL.

Answer 2

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

Как правило, я согласен с вашим подходом и придерживаюсь одного очень похожего на ваше, за исключением того, что я не определяю никаких объектов типа DAO. В большинстве случаев я не просто определяю класс менеджера, а два отдельных класса: репозиторий для управления поиском/сохранением базы данных и фабрикой для создания новых, действительных экземпляров. Это просто для того, чтобы не нарушать SRP (также я, как правило, определяю их как интерфейсы). Это хорошо сочетается с написанием модульных тестов.

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