Eiffel: Рекомендация для разработки ORM (объектной модели отношений)

Question

Рекомендации, которые я понял в Java (которая имеет множество ограничений, @ минимум для меня), даже в спящем режиме должен был быть разделенный слой

• Субъекты как люди, дети, пользователи и т.д ...
• DAO сущности, связанные с базой данных
• Служба , предоставляющая сущности и функциональные возможности, где я буду выполнять SQL
• WebService предоставление интерфейса для удовлетворения потребностей

Поскольку я начинаю с Eiffel и store, я сталкиваюсь с некоторыми трудностями, с которыми я сталкиваюсь с тех пор в программировании (надеюсь,есть кто-то на этой земле, у которого не та же самая проблема) Я всегда хочу обобщать вещи больше, чем необходимо.Каждый раз, когда я делаю копирование-вставку, я выполняю рефакторинг и ищу решение, которое позволяет мне написать его один раз ... что требует времени и времени на доставку программного обеспечения, но для меня это повышает качество и гибкостьпрограммного обеспечения.На самом деле я работаю один в компании, где я собираюсь стать ведущим разработчиком, и если будущее захочет, мы будем больше разработчиков.Цель состоит в том, чтобы разработать платформу служб в Eiffel, postgresql-odbc и клиентской части Angular-Web.

Мне бы хотелось иметь более общий шаблон для управления объектами в будущем.с типичными ситуациями:

• Сущности базы данных
• Отношения
  • one_to_one
  • one_to_many
  • many_to_one
  • many_to_many

@ Дело в том, что сейчас я собираюсь разработать архитектуру, которая в идеале для меня имеет:

• DB_ENTITY, которая какотношения: BAG [RELATIONSHIP [P, S]], где P = основной и S = ​​вторичный
• Первичный - это P-> DB_ENTITY, когда ONE, и BAG [P], когда MANY
• КОМПАНИЯ на моемдизайн унаследует от DB_ENTITY и добавит отношения как BRANCH.Поэтому я подумывал о том, чтобы иметь в своих ветвях класса COMPANY: RELATIONSHIP [например, Current, BRANCH]

Классы отношений помогли бы мне создавать операторы CRUD SQL в слое "service" более абстрактным образом.

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

Answer 1

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

Рекомендую книгу: https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software-ebook/dp/B00794TAUG/ref=sr_1_2?s=digital-text&ie=UTF8&qid=1540350158&sr=1-2&keywords=domain+driven+design&dpID=51OWGtzQLLL&preST=_SY445_QL70_&dpSrc=srch

Не только из-за шаблона Repository.

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

Некоторые плюсы и минусы шаблона Repository:

• Вы сами определяете SQL.Некоторые рассматривают это как минусы, но некоторые видят это как плюсы, потому что у вас есть четкое понимание отображения базы данных в ваши классы, и это позволяет оптимизировать ваши запросы и объединить несколько таблиц в один класс или меньше.количество классов, когда оценивается в вашем контексте.
• Больше свободы при определении модели вашего домена.Это может сильно отличаться от схемы вашей базы данных.Ваши классы не обязательно должны быть просто набором анемичных атрибутов таблиц в вашей базе данных, но они могут иметь поведение, быть полезными и выразительными в настройках, полностью независимых от вашей базы данных.
• Платформы ORM,Подобно Hibernate, иногда их трудно использовать для нового разработчика, который не очень хорошо с ними знаком.С шаблоном репозитория, поскольку отображение настолько ясно и доступно в вашем собственном коде, оно становится проще для понимания и отладки.
• Вы также можете иметь разные реализации своих репозиториев для разных технологий, таких как NoSQLбазы данных.При использовании ORM-структур вы, как правило, зависаете от реляционной базы данных, если только вы не переделываете совсем немного своих зависимостей от ORM-структуры.Проще инкапсулировать технологию хранилища данных в репозитории и поддерживать четкое разделение между моделью вашего домена и базой данных.

Я бы сказал, что это основные моменты.Сказав это, это очень общие рекомендации.У меня нет опыта работы с постоянными данными в Eiffel, поэтому я не могу сказать, каковы лучшие практики для разработчиков Eiffel.Но у меня есть ощущение, что шаблон репозитория хорошо подходит для Eiffel, потому что первоначальная цель языка заключалась в создании более абстрактных, доменных библиотек классов, что и является целью шаблона репозитория.(Кстати, я называю это шаблоном, но я не уверен, что автор называет это так. Автор, вероятно, будет называть агрегаты, сущности и репозитории, все виды классов, используемые в проектировании, управляемом доменом, все вместешаблон.)