ORM建模:首先是数据库与类

Question

我正在尝试使用Sparx Enterprise Architect来设计一个最终存在于MySQL数据库中的数据模型.

我的第一种方法是数据模型图,可用于生成DDL(或通过逆向工程反过来).

这非常有效,但是一位同事指出了一个障碍:我们打算使用ORM(几乎可以肯定是Hibernate)将表映射到Java类.他的评论是"数据库优先"方法,将排除使用良好的OO技术,如继承.

这似乎是一个好点,但我想知道是否有任何限制.如果我从头开始使用类图而不是数据模型图,是否有办法在此模型中包含所有必要的Hibernate注释,配置等？如果我后来需要建模特定于数据库的功能,例如约束,触发器等,那么在模型中,所有这些都是可能的,因为类图不是真正针对这种类型的东西吗？

Answer 1

我更喜欢先建模数据库.数据库是业务中最有价值的部分,应用程序逻辑只是操作业务数据的接口.

由于数据库往往比应用程序技术更长,因此最好先设计它,因为设计通常由数据关系和数据查询模型驱动.

大多数ORM都是为了将​​域对象建模到现有模式而设计的,它是ORM工具任务,可以处理任何可能的db模式映射conecer.

对于快速原型设计,我可能会考虑从域对象生成模式,但在设计大型企业系统体系结构时,这种方法是次优的.

Hibernate只提供有限数量的DDL功能,我不喜欢松散额外的数据库特定功能,如PosgreSQL域,代替触发器,物化视图或MySQL触发器.

像Flyway这样的工具最适合用于自动化模式迁移过程.

Answer 2

让我回答问一个问题:如果你想建房子,你会先建造它然后再打印出来,或者你会先制定计划吗？:)

软件开发就是逐渐降低抽象.我们从一个非常抽象的项目想法开始,然后做一些reqs(显然有点不那么抽象),然后架构,设计和精细地来到编码层面(最低抽象)

数据模型是最低可能抽象级别的模型(可直接映射到DDL),因此这是您要做的最后一件事.

域类模型是数据库的更高抽象.它甚至是Hibernate层的抽象,因为它还依赖于抽象的实现级别.

因此,我首先要使用类和OO的全部功能来定义域的模型.尝试使实现独立的类模型.不要假设JAVA,Hibernate,DB,任何东西,而是专注于您的域逻辑.制作一种"utopic"域模型,逻辑上完美结构化的域类.

然后使用相应的转换从此模型派生Hibernate层和DB本身.

Answer 3

无论您使用何种技术,您都应该始终"先说实话".XML接口中的真相在哪里？在其XSD规范中,不是任何语言的某些实现类.同样,与RDBMS交互时的真相在哪里？它位于数据库中,以DDL的形式编写.数据库应"拥有"其架构,而不是从某些派生的客户端表示生成.我在这里写过这个主题.

这是以对数据库重要的语言控制数据库模式的唯一合理方法.这也是合理的唯一方法:

• 上线后进化模式,不能简单地再次删除并重新创建模式
• 控制数据库性能,尤其是在编写SQL查询而不是使用ORM导航实体时.

我们打算使用ORM(几乎可以肯定是Hibernate)将表映射到Java类.他的评论是"数据库优先"方法,将排除使用良好的OO技术,如继承.

您应该首先问自己为什么需要继承.由于您使用关系模型存储数据,因此应使用关系模型的建模功能,并且应从中派生所有客户端表示(例如,您的ORM).在非常罕见的情况下,继承甚至是这个领域中可行的建模技术,并且大多数仍然不能很好地工作,因为经过20多年的OO,人们得出结论,在OO的早期阶段过度使用继承 - 特别是继承数据结构.组合应该受到青睐,并且无论如何都是更关系的.

有可能你的关系模型将比你的OO客户端表示更长,你应该确保关系模型是健全的和规范化的,等等.

这似乎是一个好点,但我想知道是否有任何限制.如果我从头开始使用类图而不是数据模型图,是否有办法在此模型中包含所有必要的Hibernate注释,配置等？如果我后来需要建模特定于数据库的功能,例如约束,触发器等,那么在模型中,所有这些都是可能的,因为类图不是真正针对这种类型的东西吗？

我认为您不需要通过派生类图导航数据库模型.考虑您的ERD(您可以从DDL生成).ORM的表示将简单地反映出这一点.