您是否创建类来处理“实体”？ 对于数据驱动的应用程序？
我是一个新手，在创建数据库应用程序时，我总是只是创建我的表单并将所有代码和绑定放在那里。 我没有使用数组和列表来保存信息，而是直接对数据库进行了更改。
现在我已经有了一些进步，假设我向客户出售小部件并将销售信息保存在数据库中。 如果我正在编写一个程序来访问数据库，我是否不想创建一个“Customer”和“Widget”类型的类来处理这些实体？
如果我错了，那么编程数据库应用程序的适当方法是什么？
I'm a newbie and when messing around with creating database applications I always just created my forms and put all the code and bindings in there. Instead of having arrays and lists that held information I made changes to the database directly.
Now that I have evolved a little bit let's say that I sold widgets to customers and kept the sales information in a database. If I were writing a program to access the database wouldn't I want to create a class of type 'Customer' and 'Widget' to work with those entities?
If I'm mistaken then what is the appropriate approach to programming database applications?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的。
您想要研究n 层编程。
基本上，您只允许前端（表示层）访问您的类库（业务层）。 然后您的类库访问您的数据库。
这为您提供了一个不太紧密耦合的解决方案，并允许更易于维护的代码。 此外，通过引入层，您可以更改数据库，而无需在前端重写代码，只要不需要更改与业务层的接口即可。
就绑定而言，如果您使用 Visual Studio Windows 窗体（2005 年起），您应该能够使用 bindingSource 然后您可以使用它来绑定控件。 如果您使用的是 ASP.NET，那么您的控件应该绑定到对象列表，没有任何问题。
对于 ASP.Net，ObjectDataSource 可能值得研究。 我自己没有使用过，但是网上有很多示例。 请尝试此处或此处。
Yes.
You want to look into n-tier programming.
Basically, you allow you front end (presentation layer) access only to your class library (business layer). Your class library then accesses you database.
This gives you a less tightly coupled solution, and allows for more maintainable code. Also by introducing tiers you allow for changes to your DB without the need to rewrite code in your frontend, as long as the interface with the Business Layer doesn't need to be changed.
As far as binding is concerned, if you are using Visual Studio Windows Forms (2005 onwards) you should be able to us an bindingSource that you can then use to bind your controls. If you are using ASP.NET then your control should bind to a list of objects without any problems.
For ASP.Net the ObjectDataSource might be worth looking into. I haven't used it myself, but there's lots of samples on the web. Try here or here.
是的。
您需要仔细查看对象关系映射。
您的现实世界业务实体是通过映射到关系表的对象来建模的。
Yes.
You want to look closely at Object-Relational Mapping.
Your real-world business entities are modeled by objects which map to relational tables.
您不希望表示层直接依赖于数据库结构； 问题是，如果您的数据库结构发生任何变化，您的表示层也必须发生变化，从长远来看，这往往会导致问题。 此外，让表示层直接与数据库交互还涉及安全问题。
这里的粗略比喻是市场； 当你去商店买一条面包时，你不需要知道如何种植小麦； 你只需要知道你有钱，他们有面包，他们会用一定数量的面包换一定数量的钱。 您不需要知道一年中的什么时间种植小麦，或者如何去除谷壳，或者任何其他的，因为背衬层会为您处理这些事情。 同样，农民不需要知道如何向一大群人卖面包，甚至不需要知道如何制作面包；他只需要知道如何做面包。 他所要做的就是知道如何种植小麦。
现代设计理念建议您使用中间层在表示层和数据库层之间进行交互； 这是您放置业务逻辑的地方。 举例来说，假设您在网站上销售小部件。 您不必让演示代码查询数据库中的小部件并显示它，而是使用一个处理您的小部件的业务对象。 这样，您的业务对象需要知道您的数据库结构是什么，但您的表示层只需要知道如何向您的业务对象请求要显示的小部件列表。 更重要的是，在您的业务对象中，您可以放置在某些事情发生时要调用的规则。 因此，您的业务对象知道如何进行更改以及当表示层请求进行销售时要修改哪些表，而不是在下订单时表示层直接对库存和订单数据库进行更改。
通过这种方式，您可以将信息的显示与网站的持久性和逻辑分开。 所涉及的是良好的规划； 具体来说，您必须弄清楚您的网站在任何给定点将执行什么操作，以及这对于您的业务对象将提供哪些接口意味着什么。 然后，您根据这些需求实现您的业务对象； 这些业务对象是您放置数据库结构知识和特定业务逻辑的地方（“当 A 发生时，执行 B，然后执行 C”等）。
一开始这看起来像是很多额外的工作，但确实是值得的。
You do not want your presentation layer to directly depend on your database structure; the problem with that is if your database structure changes at all, your presentation layer must change, and in the long term, that tends to cause problems. Moreover, there are security issues involved with having your presentation layer directly interact with your database.
The rough analogy here is to markets; when you go to the store to buy a loaf of bread, you don't need to know how to grow wheat; all you need to know is that you have money, and they have bread, and that they will exchange a certain amount of bread for a certain amount of money. You don't need to know what time of year to plant the wheat, or how to remove the chaff, or any of that, because the backing layer takes care of that for you. Similarly, the farmer doesn't need to know how to sell bread to a whole bunch of people, or even how to make bread; all he has to do is know how to grow wheat.
Modern design philosophy recommends that you use an intermediate layer to interact between your presentation layer and your database layer; this is where you put your business logic. So, for example, let's say that you're selling widgets on your site. Instead of having your presentation code query the database for widgets and display that, you have a Business Object which handles your widgets. This way, your business object needs to know what your database structure is, but your presentation layer only needs to know how to ask your business object for a list of widgets to display. More importantly, in your business object you can place the rules that are to be invoked when certain things happen. So instead of your presentation layer directly making changes to the database for inventory and orders when an order is made, your business object knows how to make the changes and what tables to modify when your presentation layer requests that a sale occurs.
In this way, you separate the display of your information from the persistence and the logic underlying the website. What is involved is good planning; specifically, you have to figure out what your web site will be doing at any given point, and what that means in terms of what interfaces your business objects will provide. Then you implement your business objects based off of those requirements; those business objects are where you put the knowledge of the database structure and your specific business logic ("when A happens, do B and then C", etc.).
This seems like a lot of extra work at the beginning, but it really is worth it.