WCF/客户端应用程序 - 业务逻辑应该去哪里？
我们正在使用 WSSF 构建 WCF Web 服务。这个想法是，它将通过服务公开我们的主数据库，并允许我们在服务之上构建各种应用程序和网站。目前，我正在构建一个简单的客户端应用程序，它将从此服务下载一些数据，对其进行操作，然后将其作为报告 CSV 文件提供给用户。
现在的问题是业务逻辑（操作数据）应该位于哪里？我想我会把它放在服务中。我已经有一个业务层，其中包含简单的对象，这些对象几乎与数据库（客户、订单等）一一对应。我想我会制作一些“更高级别”的对象来操纵数据。例如，通过使用客户、订单和其他对象并生成报告等。我认为最好的位置是在服务的业务层中。这样，如果需要，我们可以为各种不同的应用程序重用此逻辑。
不幸的是我的老板不同意。他希望实现“关注点分离”，并表示该逻辑的正确位置应该是客户端应用程序内的业务层，而不是服务中。我想这可能会更简单，但我想在服务业务层中使用强大的对象模型来编写此代码。服务公开的对象不是“真正的”对象，实际上只是轻量级数据结构，没有服务业务层内存在的完整对象模型的功能。
你们觉得怎么样？
We're building a WCF Web Service using WSSF. The idea is that it will expose our main database via the service and allow us to build various applications and web sites on top of the service. At the moment I'm building a simple client app that will download some data from this service, manipulate it then give it to the user as a report CSV file.
Now the question is where should the business logic (that manipulates the data) be located? I figured that I would put it inside the service. I already have a business layer in there with simple objects that map almost one to one with the database (customer, order etc). I figured that I would make some "higher level" objects to manipulate the data. For example by using the customer, order and other objects and producing a report etc. I thought the best place for this would be in the business layer for the service. In that way we could reuse this logic for various different applications if needed.
Unfortunately my boss doesn't agree. He wants a "separation of concerns" and said that the correct place for this logic would be in a business layer inside the client app rather than in the service. I guess this could be simpler but I would like to use my powerful object model inside the service business layer to write this code. The objects exposed by the service are not "real" objects and are really just light weight data structures without the power of the full object model that exists inside the service business layer.
What do you guys think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我的投票很明确：
为什么选择数据库？
任何形状或形式的 SQL 都具有一些非常基本且非常强大的检查功能 - 确保内容是唯一的，确保表之间的关系完整性是给定的等等 - 使用它！如果您在数据库中执行这些检查，那么无论您的用户最终如何连接到您的数据（可怕的场景：经理能够使用 Excel 直接连接到您的表以执行一些商业智能工作......），那些检查将到位并得到执行。加强数据完整性是任何系统的最高要求。
为什么业务逻辑在服务器上？
其他回答者提到的原因相同：集中化。您不希望仅在客户端中拥有业务逻辑和检查。如果您公司的其他部门或第三方外部顾问突然开始使用您的服务，但所有验证和业务检查都没有到位，因为他们不知道这些，该怎么办？不是一件好事......
客户端的逻辑
是的，当然 - 您还想对客户端进行一些简单的检查，特别是如果它是一个网络应用程序。诸如“此字段是必需的”或“此字段的最大长度”等内容应尽早强制执行。理想情况下，客户端将自动从数据库/服务层获取该信息。 ASP.NET 服务器控件具有可以自动打开的客户端验证，Silverlight RIA 服务可以获取后端数据模型中的数据限制并将它们传输到客户端层。
My vote would be clear:
Why database?
SQL in any shape or form has some very basic and very powerful check capabilities - make sure stuff is unique, make sure the relational integrity between tables is a given and so on - USE IT! If you do these checks in the database, then no matter how your user ultimately connects to your data (horror scenario: managers being able to connect directly to your tables with Excel to do some Business Intelligence work......), those checks will be in place and will be enforced. Enforcing data integrity is the utmost requirement in any system.
Why business logic on the server?
Same reason the other answerers have mentioned: centralization. You do not want to have the business logic and your checks only in the client. What if some other department in your company or a third-party external consultant suddenly starts using your service, but all the validation and business checks aren't in place, since they don't know about them?? Not a good thing......
Logic in the client
Yes, of course - you also want to put some simple checks into the client, especially if it's a web app. Things like "this field is required" or "max length for this field" etc. should be enforced as early as possible. Ideally, this will be automatically picked up by the clients from the database/service layer. ASP.NET server controls have client validation which can be automatically turned on, the Silverlight RIA Services can pick up data restriction in your backend data model and transport them to the client layer.
我认为什么是“正确”取决于您的应用程序架构。关注点分离当然是有价值的。听起来你的老板觉得当前的模型是使用服务器作为数据访问层，将数据库映射到业务对象，并且业务逻辑应该在客户端实现。
无论业务逻辑是在客户端还是在服务器上实现，您仍然可以进行关注点分离。重要的不是在哪里进行处理，而是您设计应用程序各层之间的接口的干净程度。
更多地了解客户可能会有所帮助。您正在处理浏览器/Javascript 客户端吗？如果是这样，那么我会在服务器上保留尽可能多的处理，并或多或少以您希望显示的形式将数据发送到客户端。
如果它是 C# 客户端，那么您在这方面拥有更多的能力。您可以将 WCF 服务的响应重新构建到您在服务器端使用的相同业务对象类中，并获得与在服务器上相同的功能。 （只需在两个解决方案之间共享业务对象类即可。）
I think what is "correct" depends on your application architecture. There is certainly value in separation of concerns. It sounds like your boss feels that the current model is to use the server as a data access layer that maps the database to business objects and that business logic should be implemented on the client.
You can still have separation of concerns whether the business logic is implemented on the client or the server. It's not where you do the processing that counts, but how cleanly you have designed the interfaces between the tiers of the application.
It might help to know more about the client. Are you dealing with a browser/Javascript client? If so then I'd keep as much processing as possible on the server and send data to the client more or less in the form that you want it displayed.
If it's a C# client then you have a lot more power to work with on that end. You could probably reconstitute the WCF service's responses into the same business object classes you were using on the server side and get the same power that you had on the server. (Just share the business object classes between the two solutions.)
对此没有硬性规定，但在这种情况下，我会说你的老板比你错了:) 每个人对此都会有稍微不同的看法，并且可能有多种原因导致你的业务逻辑不正确放在业务层以外的地方，但很少有理由将其放在客户端应用程序中 - 您可能会争辩说，当它位于客户端应用程序中时，它是 UI 或表示规则而不是业务规则。
如果 Web 服务将由多个应用程序使用，那么您需要尽可能将业务逻辑放在 Web 服务端。我实际上有一个非常薄的 Web 服务层，它所做的就是接受调用，然后将执行传递到实际的业务层。我还将在数据库层而不是业务层中完成数据库数据和业务数据实体之间的映射。
There is no hard and fast rule for this, but in this case i would say that your boss is more wrong than you :) Everyone will have a slightly different opinion on this, and there can be a number of reasons why your business logic is put in places other than the business layer, but there is seldom a reason to put it in the client app - you could argue that when it is in the client app then it is a UI or presentation rule rather than a business rule.
If the webservices are going to be used by a number of applications, then as much as possible you want the business logic on the webservice side. I would actually have a very thin webservice layer, all it does is accept the call and then pass execution on to the actual business layer. I would also have the mapping between database data and business data entities done in the database layer, not the business layer.