您是否创建类来处理数据驱动应用程序的“实体”？答案

【问题标题】：Do you create classes to handle "entities" for data driven apps?您是否创建类来处理数据驱动应用程序的“实体”？
【发布时间】：2010-10-23 22:33:39
【问题描述】：

我是一个新手，在创建数据库应用程序时，我总是只是创建我的表单并将所有代码和绑定放在那里。我没有使用包含信息的数组和列表，而是直接对数据库进行了更改。

现在我已经发展了一点，假设我向客户销售小部件并将销售信息保存在数据库中。如果我正在编写一个访问数据库的程序，我不想创建一个类型为“客户”和“小部件”的类来处理这些实体吗？

如果我弄错了，那么对数据库应用程序进行编程的适当方法是什么？

【问题讨论】：

标签： database language-agnostic database-driven

【解决方案1】：

是的。

您想研究n-tier 编程。

基本上，您只允许前端（表示层）访问您的类库（业务层）。然后你的类库访问你的数据库。

这为您提供了一个不那么紧密耦合的解决方案，并允许更多可维护的代码。此外，通过引入层，您可以更改数据库，而无需在前端重写代码，只要不需要更改与业务层的接口即可。

就绑定而言，如果您使用的是 Visual Studio Windows 窗体（2005 年以后），您应该可以向我们提供 bindingSource，然后您可以使用它来绑定您的控件。如果您使用的是 ASP.NET，那么您的控件应该毫无问题地绑定到对象列表。

对于 ASP.Net，ObjectDataSource 可能值得研究。我自己没用过，但是网上有很多样例。试试here 或here。

【讨论】：

那么在 Visual Studio 和 .NET 中绑定和其他数据特性有什么用呢？如果您将使用“数据访问”层来为表示层提供数据，那么您不会在数据访问层中从头开始编写大部分代码吗？
没用。自从它被引入——早在 .NET 之前——我一直觉得将前端控件直接绑定到底层数据库是邪恶的。当然，只是我的看法....
好的，所以我想从头开始编写一个类来与数据库交互，并为使用我的数据库类来填充它的字段的客户编写另一个类？这比在表单上抛出一些文本框和标签并绑定控件更可取？
这将是皮特的好方法。然后，您将有四个层次。演示 -> 业务 -> 数据访问 - 数据库。这样做会给你列出的好处。重要的是保持松散耦合，例如您的数据访问层必须是与数据库通信的唯一层，您不能只让业务层直接访问它......如果您这样做，您的业务层就会变得依赖在您的数据库上进行任何更改都会影响业务层和数据访问层。

【解决方案2】：

是的。

你想仔细看看Object-Relational Mapping。

您的真实业务实体由映射到关系表的对象建模。

【讨论】：

仔细说。可能值得解释的是，“地图”并不意味着“反射”。

【解决方案3】：

您不希望您的表示层直接依赖于您的数据库结构；这样做的问题是，如果您的数据库结构发生变化，您的表示层必须发生变化，从长远来看，这往往会导致问题。此外，让您的表示层直接与您的数据库交互涉及到安全问题。

这里的粗略类比是市场；当你去商店买一条面包时，你不需要知道如何种植小麦；你只需要知道你有钱，他们有面包，他们会用一定数量的面包换一定数量的钱。你不需要知道一年中什么时候种小麦，或者如何去除谷壳，或者任何其他的，因为背衬层会为你处理这些。同样，农民不需要知道如何向一大群人出售面包，甚至不需要知道如何制作面包；他所要做的就是知道如何种植小麦。

现代设计理念建议您使用中间层在表示层和数据库层之间进行交互；这是您放置业务逻辑的地方。例如，假设您在您的网站上销售小部件。不是让您的演示代码查询数据库中的小部件并显示它，而是拥有一个处理您的小部件的业务对象。这样，您的业务对象需要知道您的数据库结构是什么，而您的表示层只需要知道如何向您的业务对象询问要显示的小部件列表。更重要的是，在您的业务对象中，您可以放置在某些事情发生时要调用的规则。因此，与您的表示层在下订单时直接更改库存和订单数据库不同，您的业务对象知道如何进行更改以及当您的表示层请求发生销售时要修改哪些表。

通过这种方式，您可以将信息的显示与网站的持久性和逻辑分开。所涉及的是良好的规划；具体来说，您必须弄清楚您的网站在任何给定时间点将做什么，以及就您的业务对象将提供的接口而言，这意味着什么。然后根据这些需求实现业务对象；这些业务对象是您放置数据库结构知识和特定业务逻辑的地方（“当 A 发生时，执行 B，然后执行 C”等）。

一开始这似乎是很多额外的工作，但确实值得。

【讨论】：