WCF/客户端应用程序-业务逻辑应该去哪里？

Question

我们正在使用WSSF构建一个WCF Web服务。它的想法是，它将通过服务公开我们的主数据库，并允许我们在服务之上构建各种应用程序和网站。目前，我正在构建一个简单的客户端应用程序，它将从该服务下载一些数据，对其进行操作，然后将其作为报告CSV文件提供给用户。

现在的问题是业务逻辑(操作数据)应该放在哪里？我想我应该把它放在服务中。我已经有了一个业务层，里面有简单的对象，几乎一对一地映射到数据库(customer，order等)。我想我应该创建一些“更高级别的”对象来操作数据。例如，通过使用customer、order和其他对象以及生成报告等，我认为最好的地方应该是服务的业务层。这样，如果需要，我们可以将此逻辑重用于各种不同的应用程序。

不幸的是，我的老板不这么认为。他想要一个“关注点分离”，并说这个逻辑的正确位置应该在客户端应用程序内部的业务层中，而不是在服务中。我想这可能会更简单，但我希望在服务业务层中使用我强大的对象模型来编写此代码。服务公开的对象不是“真正的”对象，实际上只是轻量级的数据结构，没有存在于服务业务层中的完整对象模型的强大功能。

你们觉得怎么样？

Answer 1

我的投票将是明确的：

• 将尽可能多的数据完整性检查放入数据库
• 将任何其他业务逻辑检查放入服务的服务器端的业务逻辑层
• 仅将简单的检查(如“需要字段”等)放入客户端层，最好由数据库模型或业务模型自动确定

为什么选择数据库？

任何形式或形式的SQL都有一些非常基本和非常强大的检查功能--确保内容是唯一的，确保表之间的关系完整性是给定的，等等--使用IT！如果您在数据库中执行这些检查，那么无论您的用户最终如何连接到您的数据(可怕的场景:管理人员能够使用Excel直接连接到您的表以执行某些商业智能工作……)，这些检查都将到位并将被强制执行。在任何系统中，强制数据完整性都是最高要求。

为什么选择服务器上的业务逻辑？

与其他回答者提到的原因相同:集中化。您不希望业务逻辑和检查只在客户端进行。如果您公司中的其他部门或第三方外部顾问突然开始使用您的服务，但是所有的验证和业务检查都没有到位，因为他们不知道这些情况，那该怎么办？不是一件好事......

client中的逻辑

是的，当然--你也想在客户端中加入一些简单的检查，特别是如果它是一个web应用的话。诸如“此字段为必填字段”或“此字段的最大长度”等内容应尽早强制执行。理想情况下，这将由客户端从数据库/服务层自动拾取。ASP.NET服务器控件具有可以自动打开的客户端验证，Silverlight RIA服务可以拾取后端数据模型中的数据限制并将其传输到客户端层。

Answer 2

我认为什么是“正确的”取决于你的应用程序架构。分离关注点当然是有价值的。听起来你的老板认为当前的模型是使用服务器作为数据访问层，将数据库映射到业务对象，并且业务逻辑应该在客户机上实现。

无论业务逻辑是在客户端还是在服务器上实现，您仍然可以分离关注点。重要的不是在哪里进行处理，而是应用程序各层之间的接口设计得有多干净。

了解更多关于客户的信息可能会有所帮助。你是在处理浏览器/Javascript客户端吗？如果是这样，那么我将尽可能多地在服务器上进行处理，并或多或少地以您希望显示的形式将数据发送到客户端。

如果它是一个C#客户端，那么在这一端你可以使用更多的功能。您可能会将WCF服务的响应重构为与在服务器端使用的相同的业务对象类，并获得与在服务器上相同的功能。(只需在两个解决方案之间共享业务对象类。)

Answer 3

这方面没有固定的规则，但在这种情况下，我会说你的老板比你更错误:)每个人对此都会有略微不同的看法，可能有很多原因让你的业务逻辑放在业务层之外的地方，但很少有理由把它放在客户端应用程序中-你可以争辩说，当它放在客户端应用程序中时，它是UI或表示规则，而不是业务规则。

如果used服务将由多个应用程序使用，则尽可能多地将业务逻辑放在used服务端。我实际上会有一个非常薄的webservice层，它所做的就是接受调用，然后将执行传递给实际的业务层。我还会让数据库数据和业务数据实体之间的映射在数据库层完成，而不是在业务层完成。