在构建应用程序时,您是否首先考虑数据库或对象？

Question

当你考虑构建一个应用程序,比如Web,并且它使用关系数据库时,你是先考虑数据库然后把你的应用程序作为前端,还是考虑你的程序和对象以及数据库如何存储那些.我试图改变我的想法,但它没有点击(我不确定我的评估是否正确.)

我已经问过其他的Hibernate和nHibernate问题,但我试图将其解决.我倾向于首先考虑数据库方面的数据库应用程序,然后考虑应用程序.在阅读了很多关于Hibernate的内容之后,似乎那些使用Hibernate的人会有不同的看法.他们似乎在考虑对象和类.他们与我完全相反.

并且在Hibernate的背景下.如果我倾向于首先考虑数据库方面,那么在开始时是否存在"坏"或"错误"的心态？我只能找到一些使用Hibernate或其他ORM的一致原因 - 性能,数据库不可知性,并且它从那里变化.我想使用Hibernate,但我想正确处理它.它似乎是一种完全不同的思维方式,而不仅仅是性能和选择数据库.

有关:

哪个更重要？数据库设计还是编码？.

Answer 1

显然,你会对这个问题得到很多不同的答案,但我倾向于首先考虑数据库,然后根据它来构建对象.我认为我的大脑更容易以这种方式工作,因为我可以可视化数据库模式(而且,在数据库模式中显示关系也非常容易).@Tdpi就在这里点击它:你应该根据问题领域进行设计 - 对我来说,转化为在数据库中思考,但对于不同的人来说它是不同的.

对象之间的关系并不总是那么明显,因此绘制一个显示其关系的图表更加困难.让对象继承彼此(但可能在db端使用相同的表)会让事情变得更加混乱.也就是说,在一些复杂的应用程序中,我同时完成了两个 - 例如,创建表,同时创建了多个对象从同一个基础继承的对象结构,并且都使用相同的表.

DB-first的另一个论点是大多数ORM层倾向于根据数据库模式生成对象,所以如果你设计对象,然后尝试对数据库进行逆向工程,然后让ORM生成对象,你就是做某事向后并且几乎肯定不会最终完全符合您在纸上设计的内容.

如果您正在使用基于对象为您生成数据库的ORM,那么以相反的方式执行此操作可能是有意义的,并首先设计您的对象.只要您正确地对问题域建模,如果您首先构建数据库或对象,则不那么重要.

所有这一切,其中的必然结果是当我设计应用程序的前端时,我用铅笔和纸设计它,甚至不考虑数据如何存储在后端(对象,数据库,或其他).我只是设计界面,我希望它看起来和操作.

接下来的工作就是将UI连接到后端架构,这有时非常简单,有时候并不那么简单 - 但我发现这就是构建最佳UI的方式.我经常不暴露所有功能,或者只允许配置简单设置(例如,只允许应用权限,即使后端允许继承权限也被拒绝).这意味着您的用户界面并不过分复杂,或者至少构建第一个版本更容易,但您也不会受限于制作有限的后端或将来必须彻底更改它.

当您根据数据的存储方式或您创建的对象构建UI时,它往往看起来就像 - 程序员设计的UI.