为什么不应该'；我们不把业务逻辑放在服务中吗?我们会取代我们的服务吗
本文关键字：我们 服务 取代 不应该 为什么 业务 | 更新日期: 2023-09-27 18:22:12
我正在设计一个系统，我读过很多文章，说不要在服务代码中放入业务逻辑。并且只将您的业务逻辑放在域对象中。
我没有在任何地方托管我的服务代码，它是由我的表示层直接访问的。将来，我可能希望通过WCF IIS服务公开此服务代码。
但我不明白为什么服务应该是轻量级的？它的优点是什么？我们什么时候才能更换我们的服务？请解释
其理念是通过在应用程序中具有不同的层，使其可重用。例如，您的业务层可能有一个功能来检查一本书。你可以把这个函数从不同的层调用。控制台应用程序可以调用它，服务可以调用它或网页可以调用它
此外，它更易于测试。您可以在一个只调用BLL的示例应用程序中触发该方法，而不必担心服务会调用它。
在我看来，这是关于遵守单一责任原则。一般来说，服务层的唯一职责应该是将服务操作转换为域操作。也就是说，您编写了一个服务类型，它公开了一个表示服务操作的方法，并将服务契约作为输入。服务方法将服务操作转换为域操作，并让域对象担心业务规则。通过这种方式，您的类型封装了从服务操作到域操作的转换，而不封装其他操作。
请注意，在您所指的文章中，我假设"服务"代码指的是面向服务的体系结构中的服务接口。