Camadas um serviço WCF da maneira certa

Question

A minha pergunta é mais de natureza arquitectónica, menos envolvido com a implementação real.

Eu tenho construir uma API baseada em WCF, mas realmente não pode decidir sobre como separar o PL do BL. Eu fiz meu serviço fino, de modo que ele possui apenas um mínimo de implementação, algo como:

public TagItemResponse TagItem(TagItemRequest request)
{
   return (new ItemTagRequestProcessor()).GetResponse(request);
}

Que, naturalmente, a primeira questão que se coloca, no que camada que os RequestProcessors pertencem? Eu acho que seria errado chamá-los de uma fachada, mas, ao mesmo tempo, eles não têm nada a ver com a apresentação. Por enquanto, eu decidi que, no entanto, pertencem ao PL. Os métodos de processamento tomar (DataContracts) do meu DTO como entrada, validar a mensagem de solicitação (classe base), authenticate (classe base) e, eventualmente, retornar uma única resposta DTO, assim:

protected override void Process(TagItemRequest request, TagItemResponse response, Host host)
{
    var profile = ProfileFacade.GetProfile(host, request.Profile);
    var item = ItemFacade.GetItemId(host, request.Item);
    var tags = new List<Tag>();

    foreach (var name in request.Tags)
    {
        var tag = TagFacade.GetTag(profile, name);
        ItemFacade.TagItem(item, tag);
        tags.Add(tag);
    }

    ItemFacade.UntagItem(item, tags);
}

Agora eu me pergunto, por que eu preciso as classes de fachada 1: 1 relacionados com os meus objetos de negócios. Por exemplo, tenho uma HostFacade que actua como uma camada entre o hostDAO e os processadores. Ele, no entanto, tem muito pouco a lógica, ele apenas lida com as chamadas DAO.

public static Host GetHost(HostDTO dto)
{
   return HostDAO.GetHostByCredentials(dto.Username, dto.Password);
}

Pergunta:? Eu poderia muito bem mesclar os processadores e as fachadas, certo

Eu li muitos artigos / livros sobre o assunto, mas eu ainda não pode resolver sobre a maneira 'certa' para ir e tendem a escolher uma abordagem diferente a cada vez que eu enfrentar a questão. Gostaria de saber se uma abordagem direito existe mesmo.

Eu encontrei f.ex. o exemplo doFactory, onde conversaram com as classes DAO direto da implementação do serviço. Eu realmente não gosto que, como a maioria dos métodos ServiceContract compartilhar alguma lógica, e, assim, se prestam bem para uso com classes base compartilhadas.

Eu também encontrou outros exemplos onde só as fachadas são chamados de dentro dos serviços, mas que parece funcionar bem apenas para mensagens muito mais refinado. Minhas mensagens são 'gordura' e composta, a fim de reduzir o número de chamadas para o serviço, tanto quanto possível. Meu camada extra de processamento parece a ser o meu verdadeiro problema.

Provavelmente não existe uma resposta única sobre a forma como a camada corretamente um serviço WCF, mas espero que há alguns de vocês lá fora, com uma opinião que está em conformidade meus instintos ou lançar alguma luz sobre o assunto para mim.

Thanx!

Geoffrey

Answer 1

Em primeiro lugar, presumo que por PL você camada média apresentação, não persistência camada?

Ao implementar um projeto da aplicação em camadas, a questão principal deve ser sempre:. I pode substituir a implementação de uma camada inferior, sem afetar a implementação da camada (s) acima

Isso geralmente é melhor ilustrado pela camada de persistência. Se você mudar de SQL Server 2008 para MySQL por exemplo, a camada de persistência muda (é claro). Mas são mudanças na camada de negócios também necessário? Por exemplo, faz as instâncias captura SQLEXCEPTION camada de negócios que só são lançadas por SqlClient? Em um bom design, a camada de negócios não precisa de mudanças em tudo.

O mesmo princípio deve aplicar-se a separação entre a camada de negócios e camada de apresentação.

No seu exemplo, eu diria que a ItemTagRequestProcessor não deve ser na camada de apresentação. Primeiro, ele não tem nada a ver com a apresentação, em segundo, a implementação de processamento de um pedido não é uma preocupação para a camada de apresentação. Compará-lo com uma aplicação web, apresentando uma TagItemResponse a um cliente é a preocupação da camada (apresentação) web. Recuperação de uma instância de TagItemResponse é a preocupação de uma camada por baixo da camada de apresentação.

Decidir se ter uma fachada entre a camada de negócios e persistência camada é difícil. Eu normalmente não implementar uma fachada, porque acrescenta uma camada extra (normalmente desnecessária) de engano. Além disso, não vejo um problema em chamar métodos da camada de persistência diretamente dos métodos da camada de negócios. Se somente você tomar o mesmo princípio em conta:. Você pode alterar a implementação camada de persistência, sem afetar a implementação camada de negócios

Atenciosamente,

Ronald Wildenberg