我需要业务对象吗？
我正在学习使用 C# 和 ASP.NET 以及 SQL Server 数据库进行编程。我开发了一个系统来存储和查看金融市场上的交易。基本功能是：
- 添加/更新/删除订单
- 添加/更新/删除交易（一笔交易包含一个或多个订单）
- 查看交易
- 查看订单
还有其他实体，例如经纪商、账户、策略等，支持主要订单和贸易实体。
我设计的程序有一个名为 DBUtil 的数据库实用程序类，它具有数据库的所有接口。例如，要添加新交易，我将调用 DBUtil.InsertTrade(，添加订单 DBUtil.InsertOrder(，以更新交易，DBUtil.UpdateTrade( 等。我想知道创建一个 Trade 类、一个 Order 类、一个Broker 类等。这会提高程序的优雅性、质量和可维护性吗？添加更多代码似乎没有任何好处，好吧，我现在看不到采取这种方法的好处。
据我所知，添加 Trade 类只会创建额外的代码层，因为无论如何，我都必须从 Trade 类调用 DBUtil.InsertTrade()例如，添加交易。
I'm learning to program using C# and ASP.NET with a SQL Server database. I have developed a system to store and view trades taken on a financial market. Basic functionality is:
- Add/Update/Delete an Order
- Add/Update/Delete a Trade (a trade comprises one or more orders)
- View trades
- View orders
There are other entities as well, things like Brokers, Accounts, Strategies, etc that support the main Order and Trade entities.
I have designed my program to have a Database utility class called DBUtil which has all the interfaces to the database. For example to add a new trade I would call DBUtil.InsertTrade(<params>), to add an order DBUtil.InsertOrder(<params>), to update a trade, DBUtil.UpdateTrade(<params>), etc. I was wondering if it would be better to create a Trade class, an Order class, a Broker class, etc. Would that improve the elegance, quality and maintainability of the program? It seems like adding a lot more code for no benefit, well, I can't see the benefits right now of taking such an approach.
As far as I can see adding a Trade class would simply create an extra layer of code, because I would have to call DBUtil.InsertTrade() from the Trade class anyway when adding a trade, for example.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，它将提高代码的可维护性，因为您的业务对象将是强类型的。除此之外，您可以创建测试场景，而无需使用业务对象的模型连接到真实数据库。缺点之一是当然需要编写更多代码，但这将使您在未来扩展应用程序时受益。
通常如果你使用Linq2Sql或EF，VS可以为你创建这些类。
编辑：
另请参阅这个问题为什么我们需要业务逻辑层？
Yes it will improve the maintainability of your code because your business objects will be strongly typed. In addition to that you can create a test scenario without having to connect to real database using mockup of your business objects. One of disadvantages is more code have to be written of course but it will benefit you in the future expansion of your application.
Usually if you use Linq2Sql or EF, VS can create these classes for you.
Edit:
See also this question Why do we need a business logic layer?
这实际上取决于应用程序将发展成什么样以及由谁来维护它。
如果你现在对它感到满意，那为什么要改变它呢？
我建议您阅读软件开发模式，目前听起来您正在使用 Active Record 模式，这是可以的：
http://en.wikipedia.org/wiki/Active_record_pattern
您正在考虑的是转向领域驱动设计解决方案。
http://en.wikipedia.org/wiki/Domain-driven_design
It really depends on what the application will grow into and who will maintain it.
IF you are happy with it at the minute then why change it.
I would advise you to read up on software development patterns, at the minute it sounds like you are using the Active Record pattern, and that is OK:
http://en.wikipedia.org/wiki/Active_record_pattern
What you are thinking of is moving to a Domain Driven Design solution.
http://en.wikipedia.org/wiki/Domain-driven_design
是的，域对象对于这种情况很有用。
Yes Domain object will be usefull for this case.