Superposer un service WCF dans le bon sens

Question

Ma question est plus de nature architecturale, moins impliquée dans l'implémentation actuelle.

J'ai construit une API basée sur WCF, mais je ne peux pas vraiment décider comment séparer le PL du BL. J'ai fait mon service mince, de sorte qu'il détient un minimum de mise en œuvre, quelque chose comme:

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

Than bien sûr, la première question qui se pose, dans ce que la couche ne les RequestProcessors appartiennent? Je pense qu'il serait faux de les appeler une façade, mais en même temps, ils n'ont rien à voir avec la présentation. Pour l'instant, j'ai décidé qu'ils appartiennent néanmoins au PL. Les méthodes de traitement prennent mon de DTO (de DataContracts) en entrée, valider le message de demande (classe de base), authentifie (classe de base) et éventuellement retourner une seule réponse DTO, comme ceci:

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); 
} 

Maintenant, je me demande, pourquoi Ai-je besoin des classes de façade 1: 1 liées à mes objets d'affaires. Par exemple, j'ai un HostFacade qui agit comme une couche entre le hostDAO et les processeurs. Cependant, il a très peu de logique, il traite simplement les appels DAO. Question: Je pourrais tout aussi bien fusionner les processeurs et les façades, n'est-ce pas? J'ai lu beaucoup d'articles/livres sur le sujet, mais je ne peux toujours pas me contenter du bon chemin et j'ai tendance à choisir une approche différente chaque fois que je fais face au problème. Je me demande si une bonne approche existe même.

J'ai trouvé f.ex. l'exemple de doFactory, où ils ont parlé aux classes DAO directement depuis l'implémentation du service. Je n'aime pas vraiment cela, car la plupart des méthodes de ServiceContract partagent une certaine logique, et se prêtent ainsi bien à une utilisation avec des classes de base partagées.

J'ai également trouvé d'autres exemples où seules les façades sont appelées depuis les services, mais cela ne semble bien fonctionner que pour des messages très fins. Mes messages sont «gras» et composites afin de réduire autant que possible le nombre d'appels au service. Ma couche de traitement supplémentaire semble être mon vrai problème. Il n'y a probablement pas de réponse unique à la question de savoir comment classer correctement un service WCF, mais j'espère que certains d'entre vous ont une opinion qui sera conforme à mes instincts ou apportera une nouvelle lumière sur le sujet pour moi.

Merci!

Geoffrey

Answer 1

D'abord, je suppose que par PL-vous dire la couche de présentation, pas la persistance couche? Lors de la mise en œuvre d'une conception d'application en couches, la question principale devrait toujours être: est-ce que je peux remplacer l'implémentation d'une couche inférieure sans impact sur l'implémentation de la couche (s) ci-dessus.

Ceci est généralement mieux illustré par la couche de persistance. Si vous passez de SQL Server 2008 à MySQL par exemple, la couche de persistance change (bien sûr). Mais les changements dans la couche métier sont-ils également nécessaires? Par exemple, la couche de gestion capture-t-elle les instances SqlException lancées uniquement par SqlClient? Dans un bon design, la couche de gestion n'a besoin d'aucun changement.

Le même principe devrait s'appliquer à la séparation entre la couche de gestion et la couche de présentation.

Dans votre exemple, je dirais que le ItemTagRequestProcessor ne devrait pas être dans la couche de présentation. Premièrement, cela n'a rien à voir avec la présentation, deuxièmement, l'implémentation du traitement d'une requête n'est pas un problème pour la couche de présentation. Comparez-le avec une application Web, la présentation d'un TagItemResponse à un client est la préoccupation de la couche web (présentation). La récupération d'une instance de TagItemResponse est la préoccupation d'une couche située en dessous de la couche de présentation.

La décision d'avoir une façade entre votre couche de gestion et votre couche de persistance est difficile. Je n'implémente généralement pas une façade car elle ajoute une couche d'indirection supplémentaire (généralement inutile). En outre, je ne vois pas de problème à appeler des méthodes de couche de persistance directement à partir de méthodes de couche métier. Si seulement vous tenez compte du même principe: pouvez-vous modifier l'implémentation de la couche de persistance sans affecter l'implémentation de la couche de gestion.

Cordialement,

Ronald Wildenberg