为什么我们不应该将业务逻辑放在服务中？我们会更换我们的服务吗？

Question

我正在设计一个系统，我读过很多文章说不要在你的服务代码中加入业务逻辑。并且只将您的业务逻辑放在您的域对象中。

我没有在任何地方托管我的服务代码，而是由我的表示层直接访问它。将来，我可能希望通过WCF IIS服务公开此服务代码。

但我不明白为什么服务应该轻量级？ 它的优点是什么？我们何时会更换我们的服务？请解释

Answer 1

这个想法是通过在应用程序中使用不同的层，使其可重用。例如，您的业务层可能具有签出书籍的功能。那么你可以使用该功能并从不同的层调用它。控制台应用程序可以调用它，服务可以调用它，或者网页可以调用它。

此外，它更容易测试。您可以在只调用BLL的示例应用程序中触发该方法，并且您不必担心让您的服务调用它。

Answer 2

根据我的理解，这是关于遵守single responsibility principle的。一般的想法是，服务层的单一职责应该是将服务操作转换为域操作。即您编写的服务类型公开了一个表示服务操作的方法，并将服务合同作为输入。服务方法将服务操作转换为域操作，并让域对象担心业务规则。这样，您的类型将服务操作的转换封装到域操作，而不是其他任何内容。

请注意，我假设您所引用的文章中的“服务”代码是指service oriented architecture中的服务界面。