业务逻辑类命名

Question

我有一个业务层，它有一些业务对象/ POCO /实体/等等。我还有一些数据访问存储库。到目前为止，我一直在从UI层访问存储库。我实际上需要一些不是直接CRUD的类，因此我将创建一些将执行逻辑的业务逻辑类，并且CRUD和存储库将不会被访问用户界面（可能从一开始就应该完成）。

我应该称这些课程为何？我唯一能想到的是服务类，但我在这个应用程序中有实际的WCF服务，所以这会让它变得混乱。 WCF服务也将使用这些类，因此让服务使用服务类似乎很奇怪而且令人困惑。

Answer 1

我也使用“服务”命名约定。确实，“服务”已经成为行业中一个非常过载的术语，但它最有意义。审查代码的开发人员应该能够确定应用程序/域服务与WCF服务之间的区别，并且在进行WCF服务调用时，其他服务类可能看起来令人困惑，我想你会发现它不是。服务的概念是它是执行功能的代码，并且可供其他代码使用。它可能是一个内部服务，也可能是通过http或其他任何外部公开的服务。但是代码的作用是一样的。

Answer 2

如果您的“服务”使用多个域对象编排业务逻辑，您可能正在实施Facade Pattern - 所以也许您可以使用此后缀命名它们，例如OrderManagementFacade

Answer 3

根据您的描述，听起来WCF类实际上正在实现服务主机。我通常将这些类命名为“ServiceHost”后缀。它将它们与实际的服务类很好地分开。

因此，例如，您将业务逻辑放在名为“CustomerService”的类中，相应的WCF类将命名为“CustomerServiceHost”。