Pergunta

Eu gostaria de ter a sua opinião sobre um caso específico, por favor. Trata-se de Camada de Serviço vs. Objetos auxiliares - e eu não estou à procura de padrões de idealistas, mas apenas uma boa compreensão do que meus caros colegas programação pensar sobre isso:

Na minha aplicação atual Eu tenho um modelo de domínio completo (LINQ to SQL, extremamente repositórios leves e, em seguida, os métodos de extensão uso em todo IQueryable <> Para filtrar / tipo / ordem com base em requisitos de negócios), e depois uma camada de serviço que contém serviços com base no agrupamento de responsabilidades, tais como IRegistrationService (registar utilizadores, verificação de disponibilidade de nomes de login etc.)

Agora, a ressalva. Eu também tenho algumas classes "auxiliar" que fazem coisas como criptografia, e eu também recheado outros elementos de outra forma não agrupáveis ??em que diretório (como costume enums etc.)

Eu preciso criar uma nova classe agora que vai lidar com a geração de links personalizados para o meu pedido, que é pouco mais do que String.Format com diferentes objetos e tendo suas propriedades em conta. O funcionamento interno são irrelevantes. No entanto, tenho um tempo difícil instanciar uma espécie de "LinkService" agora que vai fazer isso -. Eu sinto que vou acabar com 100 serviços (e suas interfaces + implementação) quando eu terminar

Ao mesmo tempo eu não me sinto como se eu quiser criar alguma mistura solta de aulas e outras coisas no meu "ajudantes" namespace / diretório (por exemplo LinkManager).

O que fazer? Onde você caras colocar coisas que ainda é um pouco nível de camada de negócios, mas, ao mesmo tempo, como você limitar o número de itens em sua camada de negócios / serviço? Onde você manter todas essas pequenas classes auxiliares, tais como objetos intermediários que simplificam e gerenciar o acesso de sessão (eu suponho que você quer ter este tipo forte - pelo menos eu)

?

Deixe-me saber o que você pensa? Obrigado!

Foi útil?

Solução

Para mim, usando a ferramenta certa para o trabalho é fundamental. Se você precisar de algum tipo de facilidade para gerar links, que é basicamente um mapeamento das propriedades da entidade para cordas formatados, em seguida, escrever uma facilidade para fazer isso. Ele não tem que ser um serviço ... pelo contrário, ter um serviço soprado completo para algo como isso é provavelmente um exagero. No entanto, não seria apenas fixo isso em seus "ajudantes" gerais. Parece que isso é algo que tem um propósito específico e intenção, com um tipo específico de comportamento por trás dele. Como tal, colocá-lo em um local devidamente adequado para que o comportamento ... mesmo se isso é um novo projeto.

Eu tento não ter um enorme pedaço de código "geral" em minhas aplicações. Tudo tem um propósito e implementa um comportamento específico. Às vezes o efeito e comportamento são altamente reutilizáveis, mas eu ainda tentar organizar esses elementos reutilizáveis ??de meu domínio logicamente. De um nível alto, eu ver a maioria das minhas aplicações dividida nas seguintes:

  1. Cliente
  2. API / Serviço
  3. Domínio
  4. Acesso a Dados (Opcional)
  5. Framework

Um monte de este tipo de funcionalidade reutilizável cai em uma espécie de região inferior entre Framework e Domínio. Parte disso pode existir como algumas classes base e / ou interfaces e tipos de apoio em quadro, com a outra metade, as implementações concretas, residente dentro do meu domínio. Às vezes parece estranho, mas organizando-lo desta maneira me ajuda a manter o meu domínio tão limpo quanto possível (dedicado a questões de negócios), enquanto ainda me permitindo comum abstracto e conceitos reutilizáveis ??em nível inferior tipos "quadro".

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top