Como deve objetos de nível empresarial ser chamado?

Question

Estamos construindo um sistema orientada a serviços, onde nós separamos a aplicação em várias camadas:

1. serviços web SOAP de (por exemplo, BuildingService.asmx)
2. camada de lógica de negócios (por exemplo, BuildingXXX)
3. camada de acesso a dados (por exemplo, BuildingProvider)
4. Tipos (por exemplo, Edifício)

Os serviços web SOAP de simplesmente instanciar um objeto do tipo BuildingXXX da camada de lógica de negócios, a fim de manter a implementação de serviços web SOAP. BuildingXXX então usa o BuildingProvider da camada de acesso a dados para tipos de retorno definidos na camada de objeto de transferência de dados.

Temos sido incapaz de determinar o que deve chamar os objetos na camada de lógica de negócios.

O que é a convenção de nomenclatura "padrão" para nomear essas entidades de nível negócio?

Answer 1

Pessoalmente, gostaria de chamar sua lógica de negócio dos serviços da camada "BuildingService", em seguida, chamar os serviços de web "BuildingWebService".

Ou você poderia sempre ir com o genérico "BuildingManager", bem como para a camada de serviço ..

Answer 2

Namespaces são seus amigos. Como cerca de BusinessLayer.Building, BusinessLayer.Facility? Use DataLayer.Building, DataLayer.Facility, etc. Você começa a chamar as coisas o que são, mas eles chegar a ser coisas diferentes.

Answer 3

Eu ingenuamente ir com BuildingRules (uma vez que este é o que eles são, certo?), Mas então eu não realmente sei o que são as convenções ...

Answer 4

i preferem prefixos em vez de sufixos, de modo que as camadas relacionados tipo juntos, por exemplo.

BizRuleBuilding,
BizRuleFacility,
...