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

Question

当您考虑构建一个应用程序，比如说Web，并使用关系数据库时，您是先考虑数据库，然后将应用程序作为前端，还是考虑您的程序和对象以及如何数据库可以存储这些。我试图改变我的想法，但它没有点击（我不确定我的评估是否正确。）

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

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

  

相关：

     

Which is more important? DB design or coding?

Answer 1

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

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

DB-first的另一个论点是大多数ORM层倾向于根据数据库模式生成对象，所以如果你设计对象，然后尝试对数据库进行逆向工程，然后让ORM生成对象，你就是善良的做事情倒退，几乎肯定不会最终完全符合你在纸面上的设计。

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

---

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

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

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

Answer 2

都不是。

您可以考虑问题域中需要建模的实体。无论您是将它们建模为OO对象还是数据库实体，都是一个实现细节。 （虽然我发现将名词/实体视为数据库，动词/操作更容易将其视为OO代码。）

在Hibernate或其他ORM的上下文中，我的经验是数据库更好地阐明实体之间的关系，并且设计模式会强制提出关于这些关系在现实世界中应该在模型中应该是什么的问题。这不是一个更好的模型，本身，这是一个更好的解决这些问题的过程。

Answer 3

我发现很难将两者分开。我的对象模型和我的数据模型（一般来说）倾向于最终相似。当然，有些情况下不会发生这种情况 - 所以我在推广。

在我看来，以下规则适用：

• 数据模型应设计为适应最佳性能和最佳报告设计/开发。

• 对象模型应设计为以最佳性能，可伸缩性和GUI集成将数据传输到应用程序。您不必跳过大量的箍来将数据从GUI获取到数据库或再返回。对象模型的核心通常与数据模型的核心非常相似。

• GUI应该旨在使用户的生活尽可能简单和灵活。用户不必知道/理解/关心/接触底层对象模型。

显然会出现这些指导原则并未遵循的特殊情况，但在大多数情况下，简单性是关键。

Answer 4

我总是首先考虑用户界面，毕竟，这就是客户将要看到的内容，如果您的数据库已经规范化或者您的对象设计得很好，他们也不会关心...（至少不是最终用户）。在确定界面是我想要的之后，我认为数据库第二，对象最后 - 我认为你可以在最后两个方面做出有效的案例，但我有更好的数据库背景，并倾向于喜欢使用大数据库，所以我认为一个很好的数据库设计密钥。一旦定义了UI，并且定义了数据库，那么这些对象就是使它完全起作用的粘合剂......至少在我的思维方式上。

Answer 5

这可能不是最常见的观点，但说实话，我认为这不重要。如果您在数据库方面做得更好，那就去做吧。如果您认为OO代码更好，那就去做吧。没有正确的方法来做到这一点。它们只是模拟应用程序所代表的真实世界实体的方式，这是您真正需要考虑的内容。

Answer 6

都不是。一般来说，我倾向于用“动词”来思考它;也就是说，用户将对系统做些什么。也就是说，我通过一组用例来查看用户将对系统执行的操作。一旦确定了这些，他们就可以同时指导Business Objects和数据库的创建。

从数据库开始的问题是，如果你这样做，你可以得到一个非常好的数据库，它不支持你做你想做的事情;如果你先想到对象，你就会想到结构。用户不关心您的持久性或数据的表示;他们只关心事情的完成。

Answer 7

我更喜欢先考虑对象。

对象是应用程序行为的核心部分，它将影响最终用户如何使用您的站点/应用程序，逻辑如何工作等。使对象模型正确是使项目正常工作的关键

对我来说，数据库实现只是一个实现细节。我更愿意将其视为数据的内部表示 - 我应该能够随意改变它 - 从某种意义上重构它，而不是整体改变我的项目。

我发现首先关注数据库，而不是项目空间，往往会导致开发人员走上危险的道路 - 你最终会被锁定在思考项目，而不是从用户的角度来看，而是从从数据结构的角度来看。这可能导致软件使用率降低。

Answer 8

我尽量避免使用关系数据库。 Gemstone，Prevayler，Magma允许我在没有OO的情况下做OO。 领域驱动设计也关注对象，而不是持久性。

在大多数领域，首先考虑行为和互动是有意义的，而不是考虑领域。

启动以数据库为中心的问题之一是难以创建正确的抽象。模特往往过于平坦。

Answer 9

对我而言，这相当于询问我是否首先考虑用户或程序员。如果我正在考虑最快的方法，我从数据库开始。不过，我非常努力地从对象（从用例中出来）开始;然后编写提供对象的数据库模式。 （通常他们是不同的）。如果数据库已经存在，那么更重要的是你要强迫自己设计一个好的抽象层。

Answer 10

对我而言，这是一个混合体。从1.5年前的实体框架开始，我倾向于考虑导航属性。我按照我想要的方式在纸上绘制了一些东西然后想想实体框架将如何在实体之间导航等。从这里我设计数据库，将数据库转储到实体框架模型并创建我的单元测试。然后，如果它不能流畅地导航，我会进行必要的更改。真的没有任何速度问题。

Answer 11

两个

请注意，要求和想法都应该在考虑之前完成 - 在此期间根本不用担心技术实现。

但是在构建应用程序时 - 请考虑两者。在我看来，每个程序员都应该对数据库有一个公平的想法，反之亦然。 根据对象和表格进行思考可以帮助您将事物分发给最擅长的人。 （简单示例：复杂搜索可以在多连接或文本索引sql中完成，而不是完全在java或c＃中完成。）

Answer 12

我参与了3个项目，人们试图将面向对象的设计和思维方式融入到一个“思考”不同的关系数据库中。所有这些都涉及休眠。所有这些都是出于类似原因的失败。巧合？也许。奇怪的巧合虽然......我的拙见 - 分别使用两个头。一个用于建模问题，另一个用于存储数据。对于建模，面向对象的方式是最好的。对于存储数据 - 这很痛苦。当有中间人 - 关系数据库和我们其他人之间的人时，我个人更喜欢解决方案：）