Question

Ma question est davantage de nature architecturale, moins liée à la mise en œuvre réelle.

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 simplifié mon service afin qu'il ne contienne qu'un minimum d'implémentation, par exemple:

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

Alors bien sûr que la première question se pose, à quelle couche appartiennent les RequestProcessors? Je pense que ce serait une erreur 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 appartiendraient néanmoins au PL. Les méthodes de processeur prennent en entrée mes DTO (DataContracts), valident le message de requête (classe de base), s'authentifient (classe de base) et renvoient éventuellement une seule réponse DTO, comme suit:

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

Je me demande maintenant pourquoi j'ai besoin des classes de façade 1: 1 liées à mes objets métier. Par exemple, j'ai un HostFacade qui agit comme une couche entre hostDAO et les processeurs. Cependant, il contient très peu de logique, il se contente de gérer les appels DAO.

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

Question: Je pourrais aussi bien fusionner les processeurs et les façades, non?

J'ai lu de nombreux articles / livres sur le sujet, mais je ne parviens toujours pas à me mettre sur la «bonne» voie à suivre et j'ai tendance à choisir une approche différente chaque fois que je fais face à la question. Je me demande si une bonne approche existe même.

J'ai trouvé f.ex. l'exemple doFactory, où ils ont parlé aux classes DAO directement à partir de la mise en œuvre du service. Cela ne me plaît pas vraiment, car la plupart des méthodes ServiceContract partagent une logique et se prêtent donc 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 à partir des services, mais cela ne semble bien fonctionner que pour des messages très fins. Mes messages sont "gros" 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’ya probablement pas de réponse unique quant à la manière de superposer correctement un service WCF, mais nous espérons que certains d’entre vous ont une opinion qui soit conforme à mon instinct ou jette une nouvelle lumière sur le sujet pour moi.

Merci!

Geoffrey

Était-ce utile?

La solution

Premièrement, je suppose que par PL, vous voulez dire couche de présentation, pas couche de persistance?

Lors de la mise en œuvre d’une conception d’application en couches, la question principale devrait toujours être: puis-je remplacer l’implémentation d’une couche inférieure sans impacter l’implémentation des couches 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 des changements dans la couche de gestion sont-ils également nécessaires? Par exemple, la couche de gestion intercepte-t-elle les instances SqlException qui sont uniquement levées par SqlClient? Dans une bonne conception, 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 figurer dans la couche de présentation. Premièrement, cela n'a rien à voir avec la présentation, deuxièmement, la mise en œuvre du traitement d'une demande ne concerne pas la couche de présentation. Comparez-le avec une application Web, la présentation d'un TagItemResponse à un client relève de la couche Web (présentation). La récupération d'une instance de <=> concerne une couche située sous la couche de présentation.

Il est difficile de choisir une façade entre votre couche de gestion et votre couche de persistance. En général, je n'implémente pas de façade, car elle ajoute une couche d'indirection supplémentaire (généralement inutile). De plus, je ne vois pas de problème à appeler des méthodes de couche de persistance directement à partir de méthodes de couche de commerce. Si seulement vous teniez compte du même principe: pouvez-vous modifier l’implémentation de la couche de persistance sans affecter celle de la couche de gestion.

Cordialement,

Ronald Wildenberg

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top