WCF 服务和业务逻辑
我不确定将我的业务逻辑放在哪里。我有一个 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);
}
I am unsure where to place my business logic. I have a WCF service which exposes its methods to my client.
Should my business logic go in the service method
public User GetUser(int id)
{
//Retrieve the user from a repository and perform business logic
return user;
}
or should it be in a separate class where each WCF service method will in turn call the business layer methods.
public User GetUser(int id)
{
return _userLogic.GetUser(id);
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我个人的偏好是将 WCF 作为单独业务层之上的一个非常薄的层。 WCF 层只不过是调用业务层，类似于选项 2 中所示的内容。如果您希望业务层被 WCF 客户端以外的其他对象使用（例如，一个 WPF 应用程序直接调用您的业务层，而不是通过 WCF）。
My personal preference is to have WCF as a very thin layer on top of a separate business layer. The WCF layer does nothing more than make calls to the business layer, similar to what you have shown in option 2. This gives you some flexibility in the event that you want to have your business layer consumed by something other than WCF clients (for example, a WPF application calling your business layer directly rather than via WCF).
默认情况下，WCF 服务已被设计为可重用。我认为没有理由不在你的服务中添加一些逻辑，但请记住诸如单一职责原则之类的事情，这样你就不会得到一个可以做很多事情的服务。
即使如此，如果您最终将功能划分为较小的类，那么将这些类托管为 WCF 服务也不是一个坏主意。然后，您可以在需要时在进程内（通过管道）使用它们，或者跨机器边界 (tcp) 甚至作为 Web 服务。根据需要创建外观以提供对其他较小服务的功能的访问。
没有必要避免将任何逻辑放入 WCF 服务类中。
WCF services are already, by default, designed for reuse. I see no reason not to have some logic in your services, though keep in mind things like the Single Responsibility Principle so you don't end up with a service that does a dozen things.
Even then, if you end up parceling out your functionality into smaller classes, it's not a bad idea at all to host those classes as WCF services. You can then use them in-proc (via pipes) when needed or across machine boundaries (tcp) or even as web services. Create facades as needed to provide access to the functionality of your other, smaller services.
There's no real need to avoid putting any logic in WCF service classes.
我认为这个决定取决于您的业务需求。 WCF 是一种在服务器和客户端之间传输数据（对象）的机制。如果您希望业务逻辑在服务器上运行，则应该让 WCF 在运行业务逻辑后公开该对象。
I think that the decision depends on your business needs. WCF is a mechanism to transport data (objects) between server and client. If you like your businsess logic runs on server, you should let WCF exposes the object after running your business logic.
它应该放在一组单独的类中。您的 WCF 层应该只包含与如何交付服务产品直接相关的逻辑。
在您的例子中，我看到您有一个返回 User 的 WCF 方法（我假设这是一个自定义类），为什么有一个单独的方法来返回 UserID，而不是在返回 User 对象时填充该属性？
It should go in a separate set of classes. Your WCF layer should only contain logic that directly pertains to how the product of the service is delivered.
In your case, I see that you have a WCF method that returns a User (I assume this is a custom class) why have a separate method to return the UserID instead of populating that property as part of returning the User object?
为了重用/可测试性/维护/可读性，您应该始终将 BL 放在单独的层中。
For reuse/testability/maintenance/readability you should always put you BL in a separate layer.