业务逻辑类命名
我有一个业务层,其中有一些业务对象/POCO/实体/其他内容。我还有一些用于数据访问的存储库。到目前为止,我一直直接从 UI 层访问存储库。我现在实际上需要更多一些不直接 CRUD 的类,因此我将创建一些业务逻辑类来执行逻辑和 CRUD,并且存储库将不会被UI 不再存在(这可能应该从一开始就完成)。
我应该如何称呼这些类?我唯一能想到的是服务类,但我在这个应用程序中有实际的 WCF 服务,所以这会让它变得混乱。 WCF 服务也将使用这些类,因此让服务使用服务类似乎很奇怪且令人困惑。
I have a business layer that has some business objects/POCOs/entities/whatever. I also have some repositories for the data access. Up until this point, I've been accessing the repositories directly from my UI layer. I'm at a point where I actually need some more classes that aren't straight CRUD, so I'm going to create some business logic classes that will do the logic, and CRUD, and the repositories won't be accessed by the UI anymore (which should probably have been done from the start).
What should I call these classes? The only thing I can think of are service classes, but I have actual WCF services in this application, so that will make it confusing. The WCF services will also be using these classes, so having a service use a service class seems odd and confusing.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我也使用“服务”命名约定。确实,“服务”已经成为行业中一个非常重载的术语,但它是最有意义的。审查代码的开发人员应该能够确定应用程序/域服务与 WCF 服务之间的区别,虽然让 WCF 服务调用其他服务类可能看起来令人困惑,但我认为您会发现事实并非如此。服务的想法是,它是执行功能的代码,并且可供其他代码使用。它可能是内部服务,也可能是通过 http 等方式向外部公开的服务。但代码的作用的想法是相同的。
I use the "Service" naming convention as well. It's true the "service" has become a very overloaded term in the industry, but it makes the most sense. Developers reviewing the code should be able to determine the difference between a Application/Domain Service vs a WCF service, and while having a WCF service call other service classes may seem confusing, I think you'll find that it isn't. The idea of a service is that it is code that performs a function, and is available for use by other code. It might be an internal service, or it might be a service externally exposed via http or whatever. But the idea of what the code does is the same.
如果您的“服务”使用多个域对象编排业务逻辑,您可能会实现 Facade Pattern - 所以也许你可以用这个后缀命名它们,例如
OrderManagementFacade
If your 'services' are orchestrating business logic using a number of domain objects, you're likely implementing the Facade Pattern - so perhaps you can name them with this suffix, eg
OrderManagementFacade
根据您的描述,听起来 WCF 类实际上正在实现服务主机。我通常用“ServiceHost”后缀命名此类。它将它们与实际的服务类别很好地分开。
因此,例如,您的业务逻辑将位于名为“CustomerService”的类中,相应的 WCF 类将被命名为“CustomerServiceHost”。
From your description, it sounds like the WCF classes are actually implementing a service host. I typically name such classes with a "ServiceHost" suffix. It separates them nicely from the actual service classes.
So, for example, you would have your business logic in a class named "CustomerService" and the corresponding WCF class would be named "CustomerServiceHost".