我是一个新手，在创建数据库应用程序时我总是只是创建我的表单并将所有代码和绑定放在那里。我没有使用包含信息的数组和列表，而是直接对数据库进行了更改。
现在我已经发展了一点，假设我向客户销售小部件并将销售信息保存在数据库中。如果我正在编写一个程序来访问数据库，我不想创建一个类型为“客户”和“小部件”的类来处理这些实体吗？
如果我弄错了，那么编程数据库应用程序的适当方法是什么？
问问题
123 次
3 回答
4
是的。
您想研究n 层编程。
基本上，您只允许前端（表示层）访问您的类库（业务层）。然后您的类库访问您的数据库。
这为您提供了一个不那么紧密耦合的解决方案，并允许更多可维护的代码。此外，通过引入层，您可以更改数据库，而无需在前端重写代码，只要不需要更改与业务层的接口即可。
就绑定而言，如果您使用的是 Visual Studio Windows Forms（2005 及更高版本），您应该能够使用bindingSource，然后您可以使用它来绑定您的控件。如果您使用的是 ASP.NET，那么您的控件应该毫无问题地绑定到对象列表。
对于 ASP.Net，ObjectDataSource可能值得研究。我自己没用过，但是网上有很多样例。试试这里或这里。
于 2009-05-05T15:01:51.300 回答
2
于 2009-05-05T15:04:59.653 回答
1
您不希望您的表示层直接依赖于您的数据库结构；问题在于，如果您的数据库结构发生变化，您的表示层必须发生变化，从长远来看，这往往会导致问题。此外，让表示层直接与数据库交互还涉及安全问题。
这里粗略的类比是市场。当你去商店买一条面包时，你不需要知道怎么种小麦；你只需要知道你有钱，他们有面包，他们会用一定数量的面包换成一定数量的钱。你不需要知道一年中什么时候种小麦，或者如何去除谷壳，或者任何其他的，因为背衬层会为你处理这些。同样，农民不需要知道如何向一大群人出售面包，甚至不需要知道如何制作面包；他所要做的就是知道如何种植小麦。
现代设计理念建议您使用中间层在表示层和数据库层之间进行交互；这是您放置业务逻辑的地方。例如，假设您在您的网站上销售小部件。不是让您的演示代码查询数据库中的小部件并显示它，而是拥有一个处理您的小部件的业务对象。这样，您的业务对象需要知道您的数据库结构是什么，而您的表示层只需要知道如何向您的业务对象询问要显示的小部件列表。更重要的是，在您的业务对象中，您可以放置在某些事情发生时要调用的规则。因此，当您下订单时，您的表示层不会直接更改库存和订单数据库，
通过这种方式，您将信息的显示与网站的持久性和逻辑分开。所涉及的是良好的规划；具体来说，您必须弄清楚您的网站在任何给定时间点将做什么，以及就您的业务对象将提供的接口而言，这意味着什么。然后根据这些需求实现业务对象；这些业务对象是您放置数据库结构和特定业务逻辑知识的地方（“当 A 发生时，执行 B，然后执行 C”等）。
一开始这似乎是很多额外的工作，但它确实是值得的。
于 2009-05-05T16:40:42.950 回答