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