Eiffel: рекомендации по проектированию ORM (модель объектных отношений)

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

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

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

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

  • Сущности базы данных
  • Relationships
    • one_to_one
    • один ко многим
    • многие_к_одному
    • многие_ко_многим

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

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

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

введите здесь описание изображения

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

relational-database orm eiffel
person Pipo    schedule 24.10.2018    source источник
comment
Вы перепроектируете часть состояния СУБД, не понимая при этом RM (реляционную модель). Лучшим (хотя и ошибочным) методом проектирования RM является объектно-ролевое моделирование (потомок FCO/IM и NIAM). Таблицы RM/ER представляют отношения/ассоциации. Кардиналы - это (производные совпадающие постоянные) свойства отношений, а отношение ORM / псевдо-ER - это не отношение, а FK (внешний ключ) - особый вид ограничения, следовательно, (постоянное) свойство базы данных. PS Продолжайте, и вскоре вы станете еще одним первооткрывателем анти-шаблона EAV...   -  person philipxy    schedule 25.10.2018
comment
... ORM приносят небольшую пользу - они предназначены для управления тривиальным дизайном RM (OO/3GL) реализации системы, но смысл дизайна RM состоит в том, чтобы моделировать и в целом манипулировать < я>система. Сущности базы данных — это абстракции, о которых утверждают таблицы базы данных. ORM, модели pre-RM псевдо-ER и даже ERM неправильно понимают RM. Так что изучите RM и используйте его. Там, где реляционно охарактеризованное состояние и его общие запросы слишком велики или медленны, реализуйте особые случаи состояния и методов в OO/3GL. Затем вы можете захотеть, чтобы ORM управлял состоянием OO таким образом, который также легко доступен реляционно.   -  person philipxy    schedule 25.10.2018
comment
@philipxy спасибо за все ваши комментарии, но мне трудно понять вас, не могли бы вы предоставить мне несколько ссылок или более тривиальные читаемые комментарии?   -  person Pipo    schedule 25.10.2018
comment
Если у меня будет шанс, я вернусь, думаю, я дам вам кое-что, чтобы поискать. Не знаю насчет ответа - ваш вопрос сейчас довольно расплывчатый. Как вы используете объекты, типизированные в соответствии с вашей диаграммой? Неясно, что это означает в такой модели, или для чего ее оценивать, или по сравнению с какими альтернативами. Трудно представить, что ваш вопрос становится конкретным, чтобы соответствовать Как спросить.   -  person philipxy    schedule 25.10.2018
comment
@philipxy Я постараюсь быть более конкретным и вернусь к своему вопросу, для этого мне придется пойти дальше в моей модели/реализации. Но моя идея действительно состоит в том, чтобы получить классическую модель ER в БД в моем программном обеспечении, которое я пытаюсь получить уровень абстракции для жесткого кодирования каждого оператора SQL для CRUD и отношений, если я пропустил специфику этого момента в своем вопросе   -  person Pipo    schedule 25.10.2018

Ответы (1)


arrow_upward
0
arrow_downward

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_QL70s

Не только из-за шаблона репозитория.

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

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

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

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

person Pipo    schedule 25.10.2018