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

我们正在使用WSSF构建WCF Web服务。这个想法是，它会通过服务暴露我们的主数据库，并允许我们在服务之上构建各种应用程序和网站。目前，我正在构建一个简单的客户端应用程序，该应用程序将从该服务下载一些数据，对其进行处理，然后将其作为报告CSV文件提供给用户。WCF /客户端应用程序 - 业务逻辑应该去哪里？

现在的问题是业务逻辑（操纵数据）应该放在哪里？我想我会把它放在服务里面。我已经有了一个业务层，其中包含几乎与数据库一一对应的简单对象（客户，订单等）。我认为我会制作一些“更高级别”的对象来操纵数据。例如，通过使用客户，订单和其他对象并生成报告等。我认为最好的地方在于服务的业务层。这样，如果需要，我们可以将这个逻辑用于各种不同的应用程序。

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

你们认为什么？非常感谢您的帮助。

干杯马克

来源

2009-12-02 Mark Evans

问他：如果我们需要另一个客户端，我们应该复制所有的业务逻辑，还是使用集中版本？ – 2009-12-02 01:58:15

继续使用@Rubens Farias的逻辑，如果业务逻辑需要修复并驻留在客户端，那么*所有*客户端需要更新。如果它在服务中，那么只有服务需要更新。 – 2009-12-02 02:37:10

感谢您的回复。是的，我也认为可重用性很酷。我想主要的缺点是更新服务可能会破坏所有现有客户端。 – 2009-12-02 04:15:25

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

无论业务逻辑是在客户端还是服务器上实现，您仍然可以分离关注点。这不是你处理重要的地方，而是你设计应用程序层之间接口的方式。

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

如果它是一个C＃客户端，那么在这方面你有更多的权力来处理。您可能可以将WCF服务的响应重构为您在服务器端使用的相同业务对象类，并获得与服务器上相同的权力。（只是在两个解决方案之间共享业务对象类）。

来源

2009-12-02 02:08:24

感谢您的评论。将有2个客户端组件用于WCF Web服务的特定用途。一个Asp.NET Web应用程序，也是一个.NET Windows服务。这意味着客户端不缺电。实际上，在我看来，您不能在WCF Web服务中公开标准业务对象（使用Save（）和按需加载的属性等方法）。它公开的对象是称为“数据契约”的简单数据结构。 – 2009-12-02 04:24:13

DataContract/DataMember实质上只是对象的一个接口，它决定了它如何通过网络发送。你仍然可以将各种方法放在那里。方法本身不会通过Web服务请求发送，但只要两个应用程序都使用相同的业务对象库，它们就会作为类定义的一部分存在于两端。很显然，像Save（）这样的操作只能发生在一端或另一端（Save（）必须发生在服务器上）。另一方面，客户端可以有一个调用服务保存方法的ClientSave（）方法。 – 2009-12-02 18:54:01

内特很有意思。我没有考虑过这种可能性。我认为将业务对象保留在业务层等内可能会更好。尽管这是一种从数据层对象转换为业务层对象到服务层对象的痛苦...... – 2009-12-03 04:16:10

对此没有硬性规定，但在这种情况下，我会说你的老板比你更为错误:)每个人都会有一些不同对此的看法，并且可能有多种原因将您的业务逻辑放在业务层以外的其他位置，但很少有理由将其放入客户端应用程序中 - 您可以争辩说，当它位于客户端中时应用程序，那么它是一个UI或演示规则，而不是业务规则。

如果web服务将被许多应用程序使用，那么尽可能多的你需要Web服务端的业务逻辑。我实际上有一个非常瘦的webservice层，它所做的只是接受调用，然后将执行传递给实际的业务层。我还会在数据库层中完成数据库数据和业务数据实体之间的映射，而不是业务层。

来源

2009-12-02 02:17:01 slugster

Hi Slugster 是的，这就是我的架构使用。数据层是ADO实体框架，我有一个业务层，其中包含使用实体框架对象填充的对象。该图层包含大部分代码。 WCF Web服务层使用WSSF（Web服务软件工厂）构建。该层仅将业务对象转换为WCF消息。 – 2009-12-02 04:20:01

我的投票将是明确的：

把尽可能多的数据完整性检查到数据库
放任何其他业务逻辑检查到业务逻辑层上的服务的服务器端
只需将“所需字段”等简单检查放入客户端层，根据数据库模型或您的商业模式最佳自动确定

为什么要数据库？
任何形状或形式的SQL都有一些非常基本和非常强大的检查功能 - 确保东西是唯一的，确保表之间的关系完整性是给定的等等 - USE IT！如果您在数据库中执行这些检查，那么无论您的用户如何最终连接到您的数据（恐怖场景：管理员能够使用Excel直接连接到您的表格以执行一些商业智能工作......），那些支票将到位并将执行。强化数据完整性是任何系统的最大要求。

为什么服务器上的业务逻辑？
其他答复者提到的原因相同：集中。您不希望仅在客户端拥有业务逻辑和支票。如果贵公司的其他部门或第三方外部顾问突然开始使用您的服务，但所有验证和业务检查都不到位，因为他们不知道他们？不是一件好事......

逻辑在客户端
是的，当然 - 你也想放一些简单的检查到客户端，尤其是如果它是一个Web应用程序。像“此字段是必需的”或“此字段的最大长度”等事情应该尽早实施。理想情况下，这将由客户端从数据库/服务层自动获取。 ASP.NET服务器控件具有可以自动打开的客户端验证，Silverlight RIA Services可以在后端数据模型中获取数据限制并将它们传输到客户端层。

来源

2009-12-02 05:40:13

感谢您的详细回复Marc。我当然同意你的所有评论！我想我谈论的那种逻辑是将来自多个地方的数据汇总到某种报告或导出文件中。这并不是检查完整性等。然而，从你的评论和其他人看来，大多数开发人员也会把这种事情放在服务业务层。如果我可以访问这一层的全面业务对象，而不是服务公开的轻量级数据合同，开发起来也会容易得多。干杯马克 – 2009-12-02 06:35:06

+1与警告。是否存在可能性（很快会担心现在）您的客户可能会多样化，即客户需要略微不同的逻辑，第三方使用您的服务或更广泛的用途。在这种情况下，单个集中式BLL最终可能拥有大量的控制逻辑来确定为每个客户做些什么。好吧，所以在服务层中引入一层抽象可以帮助并且通常可以做到这一点。没有理由不能在逻辑上分离关注点，而是在身体/实施方面明智地将它们放在一起。蛋糕和吃它？ – MattC 2009-12-02 08:19:03

@MATC：是的，如果你需要支持多个客户端，你的需求可能会分开。但我仍然认为，即使在服务器上有三组，五组不同的验证规则，也比拥有数十或数百个客户端更新更容易。 – 2009-12-02 09:20:23

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

回答

相关问题