我们正在使用WSSF构建WCF Web服务。我们的想法是，它将通过服务公开我们的主数据库，并允许我们在服务之上构建各种应用程序和网站。目前我正在构建一个简单的客户端应用程序，它将从此服务下载一些数据，对其进行操作，然后将其作为报告CSV文件提供给用户。
现在问题是应该在哪里定位业务逻辑（操纵数据）？我想我会把它放在服务中。我已经有一个业务层，其中有简单的对象，几乎与数据库（客户，订单等）一对一映射。我想我会制作一些“更高级别”的对象来操纵数据。例如，通过使用客户，订单和其他对象并生成报告等。我认为最好的地方是服务的业务层。这样，如果需要，我们可以将这种逻辑重用于各种不同的应用程序。
不幸的是我的老板不同意。他希望“关注点分离”，并说这个逻辑的正确位置是在客户端应用程序内部的业务层而不是服务中。我想这可能更简单，但我想在服务业务层内使用我强大的对象模型来编写此代码。服务公开的对象不是“真实”对象，实际上只是轻量级数据结构，没有服务业务层内部存在的完整对象模型的强大功能。
你们觉得怎么样？
答案 0 :(得分：7)
我的投票很清楚：
为何选择数据库？
任何形状或形式的SQL都有一些非常基本且非常强大的检查功能 - 确保内容是唯一的，确保表之间的关系完整性是给定的等等 - 使用IT ！如果您在数据库中进行这些检查，那么无论您的用户最终如何连接到您的数据（恐怖场景：管理员能够使用Excel直接连接到您的桌面以执行某些商业智能工作......），那些支票将到位并将予以执行。强制数据完整性是任何系统中的最高要求。
为什么服务器上有业务逻辑？
其他回答者提到的原因相同：集中化。您不希望仅在客户端中拥有业务逻辑和检查。如果您公司的其他部门或第三方外部顾问突然开始使用您的服务，但所有的验证和业务检查都没有到位，因为他们不知道他们怎么办？不是一件好事......
客户端中的逻辑
是的，当然 - 您还想对客户端进行一些简单的检查，特别是如果它是一个Web应用程序。应该尽早执行“需要此字段”或“此字段的最大长度”等内容。理想情况下，客户端会从数据库/服务层自动获取此信息。 ASP.NET服务器控件具有可以自动打开的客户端验证，Silverlight RIA服务可以在后端数据模型中获取数据限制并将它们传输到客户端层。
答案 1 :(得分：0)
我认为什么是“正确的”取决于您的应用程序架构。关注点分离肯定有价值。听起来你的老板认为当前的模型是将服务器用作将数据库映射到业务对象的数据访问层，并且应该在客户端上实现业务逻辑。
无论业务逻辑是在客户端还是在服务器上实现，您仍然可以分离关注点。这不是你进行重要处理的地方，而是你设计应用程序层之间接口的干净程度。
了解有关客户的更多信息可能会有所帮助。你在处理浏览器/ Javascript客户端吗？如果是这样，那么我会在服务器上保留尽可能多的处理，并以您希望它显示的形式或多或少地向客户端发送数据。
如果它是C＃客户端，那么您可以在此端使用更多功能。您可能可以将WCF服务的响应重新组合到您在服务器端使用的相同业务对象类中，并获得与服务器上相同的功能。 （只需在两个解决方案之间共享业务对象类。）
答案 2 :(得分：0)
对此没有严格的规定，但在这种情况下，我会说你的老板比你错了:)每个人对此都有不同的看法，并且可能有很多原因导致你业务逻辑放在业务层以外的地方，但很少有理由把它放在客户端应用程序中 - 你可以说当它在客户端应用程序中时它是一个UI或表示规则而不是业务规则
如果Web服务将被许多应用程序使用，那么您需要尽可能多地在Web服务端使用业务逻辑。我实际上有一个非常瘦的webservice层，它所做的只是接受调用，然后将执行传递给实际的业务层。我还要在数据库层而不是业务层中完成数据库数据和业务数据实体之间的映射。