埃菲尔铁塔：有关ORM（对象关系模型）设计的建议

Question

我在Java中理解的建议（有很多限制，至少对我而言是这样），即使使用休眠模式，也要具有单独的层

• 实体，例如人物，孩子，用户等...
链接到数据库的
• DAO 实体
• 服务，提供实体和功能，我将在其中进行SQL
• WebService 根据需要提供界面

在我从埃菲尔铁塔和商店开始时，我遇到了自编程以来就面临的一些困难（希望这个地球上有人不存在相同的问题），我总是想对事情进行归纳。每次我执行复制粘贴操作时，我都会重构并寻找一种解决方案，使我能够一次编写它……这在交付软件时需要花费时间和时间，但是对我来说，这增加了质量和灵活性软件。我实际上是在一家公司工作，我将成为首席开发人员，如果将来需要，我们将成为更多开发人员。目标是在Eiffel，postgresql-odbc和Angular-web前端中开发服务平台。

我希望拥有更通用的模式，以便将来能够在以下典型情况下管理实体：

• 数据库实体
• 关系
  • one_to_one
  • one_to_many
  • many_to_one
  • many_to_many

@我现在要说的是，我要开发一种对我来说理想的架构：

• 作为关系的DB_EN​​TITY：BAG [RELATIONSHIP [P，S]]，其中P =主要，S =次要
• 当ONE为1时，主变量为P-> DB_EN​​TITY；当为MANY时，则为BAG [P]
• 我设计的公司将从DB_EN​​TITY继承，并将关系添加为BRANCH。所以我当时想在我的COMPANY类分支中：RELATIONSHIP [例如Current，BRANCH]

关系类将帮助我以更抽象的方式在“服务”层中创建CRUD SQL语句。

• 当我尝试更轻量的东西时，我发现必须重复操作的方式受到限制...这有点困难
• 您是否想到我在开发的第一阶段就创建的这种模型的任何缺点？

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

     

不仅仅是因为存储库模式。

     

您应该能够实现可重用的抽象类，   存储库模式，如果您想摆脱重复的代码。在   Java，MyBatis是一个可以帮助实现这一目标的框架。我真的不知道   如果在埃菲尔铁塔中有任何等效的我也是新来的埃菲尔   开发人员。

     

存储库模式的一些优缺点：

     

  
• 您可以自己定义SQL。有些人将其视为利弊，但有些人则将其视为利弊，因为您对   数据库到您的班级，它使您可以优化自己的   查询，并将多个表连接到一个或更少的类中   在您的上下文中适合的班级数量。
  
• 在定义域模型方面拥有更大的自由度。它可能与数据库的模式完全不同。您的课程不必   只是表中一组贫血的属性持有人   数据库，但是它们可以具有行为，并且在   设置完全独立于您的数据库。
  像Hibernate这样的
• ORM框架有时对于不太熟悉它们的新开发人员来说很难使用。使用存储库模式，   因为映射是如此清晰并在您自己的代码中可用，所以它   往往更易于理解和调试。
  
• 对于不同的技术（例如NoSQL数据库），您还可以对存储库执行不同的实现。有了ORM框架，   除非您重做，否则您往往会陷入关系数据库中   您对ORM框架的依赖性很大。更容易   将数据存储技术封装在存储库后面，并保持   域模型和数据库之间的清晰分隔。
  

     

我要说的是重点。话虽如此，这些非常   一般准则。我没有持久数据的经验   在埃菲尔铁塔上，所以我无法说出埃菲尔铁塔的最佳做法是什么   开发人员。但是我有一种直觉，认为存储库模式适合   埃菲尔（Eiffel）很好，因为该语言的最初目标是建立   更抽象，领域更丰富的类库，这是目的   在存储库模式后面。 （顺便说一句，我称之为模式，   但我不确定作者是否这样称呼。作者可能会   调用集合，实体和存储库，使用的各种类   在域驱动设计中，所有这些都是一种模式。）