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