代码之家 › 专栏 › 技术社区 › Pete

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

database-driven language-agnostic database

2

Pete · 技术社区 · 17 年前

我是个新手,当我忙于创建数据库应用程序时,我总是创建表单,并将所有代码和绑定放在其中。我没有使用保存信息的数组和列表,而是直接对数据库进行了更改。

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

如果我错了,那么对数据库应用程序进行编程的合适方法是什么?

3 回复 | 直到 12 年前

1

4

Mikael Engver 12 年前

对。

你想调查一下 n-tier 编程。

基本上,您只允许前端(表示层)访问类库(业务层)。然后类库访问数据库。

这为您提供了一个不太紧密耦合的解决方案,并允许使用更多可维护的代码。此外,通过引入层,您可以在不需要重写前端代码的情况下对数据库进行更改,只要与业务层的接口不需要更改。

就绑定而言,如果您使用的是Visual Studio Windows窗体(2005以后的版本),那么您应该能够 bindingSource 然后可以用来绑定控件。如果您使用的是ASP.NET,那么您的控件应该绑定到对象列表,而不会出现任何问题。

对于ASP.NET ObjectDataSource 可能值得一看。我自己没有用过,但是网上有很多样品。尝试 here 或 here .

2

S.Lott 17 年前

对。

你想仔细看看 Object-Relational Mapping .

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

3

1

Paul Sonier 17 年前

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

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

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

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

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