wcf - WCF 服务和业务逻辑

Question

我不确定在哪里放置我的业务逻辑。我有一个 WCF 服务，它向我的客户公开它的方法。

我的业务逻辑是否应该进入服务方法

public User GetUser(int id)
{  
     //Retrieve the user from a repository and perform business logic
     return user;
}

或者它应该在一个单独的类中，每个 WCF 服务方法将依次调用业务层方法。

public User GetUser(int id)
{  
     return _userLogic.GetUser(id);
}

score 8 · Accepted Answer

我个人的偏好是将 WCF 作为单独的业务层之上的一个非常薄的层。WCF 层仅对业务层进行调用，类似于您在选项 2 中显示的内容。如果您希望业务层由 WCF 客户端以外的其他对象使用（例如，一个 WPF 应用程序直接调用您的业务层，而不是通过 WCF）。

score 2 · Accepted Answer

默认情况下，WCF 服务已经设计为可重用。我认为没有理由在您的服务中不包含一些逻辑，但请记住单一职责原则之类的东西，这样您就不会最终得到一个做十几件事的服务。

即使这样，如果您最终将您的功能打包到更小的类中，那么将这些类作为 WCF 服务托管也不是一个坏主意。然后，您可以在需要时或跨机器边界 (tcp) 甚至作为 Web 服务在进程内（通过管道）使用它们。根据需要创建外观以提供对其他较小服务功能的访问。

没有真正需要避免在 WCF 服务类中放置任何逻辑。

score 2 · Accepted Answer

我认为该决定取决于您的业务需求。WCF 是一种在服务器和客户端之间传输数据（对象）的机制。如果您喜欢您的业务逻辑在服务器上运行，您应该让 WCF 在运行您的业务逻辑后公开对象。

score 1 · Accepted Answer

它应该放在一组单独的类中。您的 WCF 层应仅包含与服务产品交付方式直接相关的逻辑。

在您的情况下，我看到您有一个返回 User 的 WCF 方法（我假设这是一个自定义类）为什么有一个单独的方法来返回 UserID 而不是填充该属性作为返回 User 对象的一部分？

score 0 · Accepted Answer

0

为了重用/可测试性/维护/可读性，您应该始终将 BL 放在单独的层中。

于 2011-12-05T16:47:06.617 回答

5 回答 5