Критика ORM

Уровень 0 · материалов: 3

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

Общие признаки: недостатки Object-Relational Mapping, противоречие объектно-ориентированного и реляционного подходов, архитектура взаимодействия базы данных и кода

Группа выше: Критика ORM и границы её применимости

Материалы

• #21218 — The Fundamental Impossibility of Universal ORM — Представитель этого кластера

  ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно — maslyaev

  Смысл: The main idea is that Object-Relational Mapping (ORM) is fundamentally flawed because it tries to unify two incompatible paradigms: the mathematical logic of relational databases (facts) and the heuristic nature of object-oriented programming (objects). The author suggests that the only 'good' ORM is no ORM at all, recommending instead the use of problem-oriented APIs and a clear distinction between stored facts and operational objects.

  Universal ORMs are fundamentally impossible and counterproductive because they attempt to bridge the gap between mathematical relational facts and loose object-oriented practices.

• #16886 — ORM as a Detrimental Anti-Pattern

  ORM — отвратительный анти-паттерн — Mauzzz0

  Смысл: The main idea is that ORM frameworks are fundamentally flawed because they destroy object encapsulation; instead, database interactions should be encapsulated within 'SQL-speaking objects' to adhere to true OOP principles.

  The author argues that ORMs are an anti-pattern that breaks OOP and proposes using 'SQL-speaking objects' to properly encapsulate database logic.

• #6338 — The Pitfalls of ORM and Database Design

  ORM или как забыть о проектировании БД — metej

  Смысл: The main idea is that ORM tools should not replace proper database design. The author argues that relationships between objects should be treated as separate entities in the database to ensure flexibility, scalability, and data integrity, rather than being hard-coded as foreign keys within object tables.

  The author criticizes the tendency of programmers to let ORM tools dictate poor database design, advocating for a strict separation between object properties and relationships to ensure architectural flexibility.