Est-il essentiel de créer une couche de service?

68

J'ai commencé à construire une application en 3 couches (DAL, BL, UI) [elle traite principalement du CRM, de certains rapports de vente et de l'inventaire].

Un collègue m'a dit que je devais passer au modèle de couche de service, que les développeurs sont venus au service de modèle de leur expérience et que c'est la meilleure approche pour concevoir la plupart des applications. Il a dit qu'il serait beaucoup plus facile de maintenir l'application à l'avenir de cette façon.

Personnellement, j’ai l’impression que cela ne fait que compliquer les choses et que je ne vois pas l’avantage qu’il en tirerait qui justifierait cela.

Cette application a une petite interface utilisateur supplémentaire qui utilise quelques-unes (mais seulement quelques-unes) des fonctions de l'application de bureau. Je me suis donc retrouvé en train de dupliquer du code (mais pas beaucoup). Juste à cause de la duplication de code, je ne voudrais pas le convertir en service, mais il a dit que je devrais l'utiliser de toute façon parce qu'en général c'est une très bonne architecture, pourquoi les programmeurs sont si passionnés par les services ??

J'ai essayé de chercher sur Google mais je suis toujours confus et je ne peux pas décider quoi faire.

BornToCode
la source

Réponses:

58

Le livre de Martin Fowler "Patterns of Enterprise Architecture" dit:

La question plus facile à répondre est probablement quand ne pas l'utiliser. Vous n'avez probablement pas besoin d'une couche de service si la logique métier de votre application ne comporte qu'un seul type de client (une interface utilisateur, par exemple) et que ses réponses de cas d'utilisation n'impliquent pas plusieurs ressources transactionnelles. [...]

Mais dès que vous envisagez un deuxième type de client ou une deuxième ressource transactionnelle dans les réponses aux cas d'utilisation, il est rentable de concevoir une couche de service dès le début.

L'avantage d'une couche de service est qu'elle définit un ensemble commun d'opérations d'application disponibles pour différents clients et coordonne la réponse dans chaque opération. Si votre application comporte plusieurs types de clients qui utilisent sa logique métier et ont des cas d'utilisation complexes impliquant plusieurs ressources transactionnelles, il est judicieux d'inclure une couche de service avec des transactions gérées.

Avec CRM, Ventes et Inventaire, il y aura beaucoup de cas d'utilisation de type CRUD pour lesquels il y a presque toujours une correspondance un à un avec les opérations de la couche de service. Les réponses à la création, à la mise à jour ou à la suppression d'un objet de domaine doivent être coordonnées et traitées de manière atomique par les opérations de la couche service.

L’avantage d’une couche de service est qu’elle peut être conçue pour une invocation locale ou à distance, ou les deux, et vous donne la flexibilité de le faire. Le modèle jette les bases de la mise en œuvre encapsulée de la logique métier d'une application et de l'invocation de cette logique par différents clients de manière cohérente. Cela signifie également que vous réduisez / supprimez la duplication de code, car vos clients partagent les mêmes services communs. Vous pouvez également potentiellement réduire les coûts de maintenance. En effet, lorsque la logique de votre entreprise change, vous ne devez (généralement) modifier que le service, et non chacun des clients.

En résumé, il est bon d’utiliser une couche de service - davantage. Je pense donc que dans votre exemple, vous avez donné l’impression que vous semblez avoir plusieurs clients de logique métier.

Déco
la source
2
Il est intéressant de noter que Martin Fowler plaide contre la même interface pour les invocations locales et distantes, en faisant valoir que la différence de performances considérable en matière d’invocation distante impose une interface plus fine.
psr
Je ne comprenais pas tout à fait votre paragraphe With CRM, Sales and Inventory there will be a lot of CRUD-type use cases of which there is almost always a one-to-one correspondence with Service Layer operations- s’il s’agissait de plusieurs interfaces utilisateur, comment le CRUD intervient-il ici? Et si je n'avais pas besoin de plusieurs interfaces utilisateur alors que le CRUD fonctionnait bien avec les services, je ne créerais toujours pas une couche de services, si je comprenais bien, et j'espère vraiment que je l'aurais fait parce que je préfère garder les choses simples (la couche de services est une désordre à mon opinion inexpérimentée)
BornToCode
4
Dans ces cas, il est rare qu’un seul client puisse en profiter. Si vous ne disposiez que d'une seule interface utilisateur, je peux penser à deux raisons pour lesquelles vous souhaitez toujours utiliser la couche de service: la sécurité et la réutilisabilité. Dans une configuration d'entreprise typique, l'application d'interface utilisateur serait disponible pour les clients externes et votre couche de service uniquement disponible sur le réseau. Ainsi, le serveur Web attribue le travail à une partie verrouillée de votre réseau. Dans l'exemple de vente, vous pourriez avoir à réutiliser si vous prenez les ventes de votre site Web et développez-les sur eBay ou Amazon. Maintenant, vous avez une interface utilisateur, mais plusieurs clients.
Phil Patterson
5
Juste pour ajouter au commentaire de @PhilPatterson. Plusieurs clients ne doivent pas seulement être basés sur l'interface utilisateur. Pensez aux services Web ou aux bibliothèques - ils peuvent aussi être des clients. Votre interface utilisateur front-end peut utiliser la couche de service, ainsi que les services logiciels que vous packagez et laisser utiliser par une autre personne.
Déco
pouvez-vous fournir un exemple de couche de service?
user962206
34

Ajouter une couche de service parce que vous avez évalué l’idée et conclu que c’est la meilleure approche: bonne

Ajouter une couche de service parce que c'est ce que font tous les enfants cools: mauvais

Si votre instinct dit que vous n'en avez pas besoin, n'en faites pas.

L’un des développements les plus décevants dans le monde de la programmation au cours des 10 dernières années est qu’il s’est tourné de manière ennuyeuse vers la «mode», les gens suivant les tendances et les pionniers comme si c’était les chaussures de cette saison. Ne tombez pas dans ce piège. Parce que la saison prochaine, "tout le monde" vous dira que vous auriez dû le concevoir autrement.

Il n'y a rien de mal à faire avec une couche de service - c'est une approche particulière dont la pertinence doit être évaluée sur ses mérites techniques pour le projet en cours. Ne vous sentez pas obligé de substituer les opinions des autres à votre propre jugement.

Grand maître b
la source
27
Cela ne traite pas du tout du sujet, il se contente de faire une déclaration générale sur les pratiques de développement qui, après avoir substitué quelques mots, pourraient s’appliquer à presque toutes les questions de ce site. À la lecture de cette réponse, je suis sais même pas convaincu que vous exactement ce qu'est une couche de service est .
Aaronaught
12
Cela peut certainement être appliqué à d'autres questions ... ne le rend pas moins vrai. Le fait est que ni vous ni moi n’avons le contexte nécessaire pour énoncer ce dont il a besoin dans son projet; lui dire que oui, il en a besoin, ou non, c’est une conjecture totale et un manque de professionnalisme. Ce dont le PO a besoin, c’est un peu de soutien moral pour prendre les décisions qu'il sait être les bonnes.
GrandmasterB
5
@Aaronaught Quelle que soit l'exactitude de la réponse, il répond toujours essentiellement à la question principale: "À quel point une couche de service est-elle essentielle?". Il prétend pas du tout essentiel et que c'est peut-être juste une lubie. Si vous n’êtes pas d’accord avec la réponse, faites un vote par
maple_shaft
2
@GrandmasterB Je dirais que les modes sont bonnes dans le développement de logiciels. La plupart des développeurs sont trop novateurs ou trop incompétents pour prendre des décisions de conception et d'architecture éclairées. Nous nous attendons toujours à ce qu’ils développent un semblant de logiciel fonctionnel, de sorte que le fait de suivre le mouvement et d’être cohérent avec un choix de conception médiocre est de loin préférable et plus facile à gérer que ce qu’on faisait il ya des années, où le code de cowboy était le même. n'a pas compris ou apprécié.
maple_shaft
10
@maple_shaft Juste pour clarifier, je ne dis pas que les couches de service sont une mode. Je dis, sur la base de la façon dont la question a été posée, qu'il semble que ses collègues ont un comportement à la mode / tendance en train de le pousser à utiliser une architecture qu'il pense ne pas être méritée dans son projet. Je précise clairement dans ma réponse que je considère les couches de service (ou tout autre concept) comme un concept: des concepts neutres dont la pertinence devrait être évaluée individuellement pour chaque projet. Ils ne devraient pas être appliqués / utilisés lorsque votre propre jugement indique qu'ils ne sont pas nécessaires.
GrandmasterB
22

La décision de créer une couche de service dépend de nombreux facteurs. J'ai créé des couches de service dans le passé pour les raisons suivantes.

  1. Code devant être réutilisé par plusieurs clients.
  2. Bibliothèques tierces pour lesquelles nous avons des licences limitées.
  3. Les tiers qui ont besoin d’un point d’intégration dans notre système.
  4. Centraliser la logique métier dupliquée.

Cas 1: Vous créez une fonctionnalité de base qui doit être utilisée par une multitude de clients. La couche de service crée des fonctionnalités pour différents clients afin de puiser dans les fonctionnalités fournies immédiatement.

Cas 2: Vous hébergez normalement du code dans une application, mais vous utilisez une bibliothèque tierce pour laquelle vous disposez de licences limitées. Dans ce cas, vous avez une ressource que vous souhaitez utiliser partout, mais seulement un nombre limité d’entre elles. Si vous l'hébergez derrière un service, votre organisation tout entière peut en tirer parti à partir de leurs applications sans avoir à acheter une licence pour chaque hébergement individuel.

Cas 3: Vous créez une fonctionnalité pour que des tiers puissent communiquer avec vous. Dans votre exemple, vous pouvez configurer un point de terminaison d'inventaire pour permettre aux fournisseurs de vous transmettre des messages sur les envois de produits entrants.

Cas n ° 4: Vous avez analysé votre code à l’échelle de votre entreprise et constaté que des équipes distinctes avaient créé la même chose (la mise en œuvre était légèrement différente). Avec une couche de service, vous pouvez choisir la ou les meilleures approches et maintenant, vous pouvez implémenter le processus de la même manière pour toutes les équipes en les faisant appeler. Un autre avantage de la logique centralisatrice réside dans la découverte de bogues. Maintenant, vous pouvez déployer le correctif une fois et tous les clients profitent des avantages en même temps.

Tout cela étant dit, il existe des inconvénients potentiels pour une couche de service.

  1. Ajoute la complexité du système. Là où vous n'aviez auparavant qu'une seule application à déboguer, vous en avez maintenant deux. Les problèmes de production nécessitent la vérification des paramètres des applications client, des paramètres des applications de service ou des problèmes de communication entre des applications client et serveur configurées correctement. Cela peut être délicat si vous ne l'avez jamais fait auparavant.
  2. Un point d'échec. En cas de panne de service, tous les clients sont concernés. Lorsque le code n'est pas déployé de cette manière, le risque peut être moindre (bien qu'il existe des moyens de le réduire).
  3. Le contrôle de version peut être plus difficile à faire. Lorsque vous utilisez une application utilisant un service déployant une interface, des modifications peuvent être apportées simultanément. Lorsque vous avez plusieurs clients, vous devez gérer qui est sur la V1, qui est sur la V2 et coordonner la suppression de la V1 (une fois que vous savez que tout le monde a mis à jour vers la V2).

Le point principal est que ce n’est pas toujours un slam dunk de rendre votre système orienté services. D'après mon expérience, c'est généralement une bonne idée (j'ai tendance à structurer les applications de cette manière), mais ce n'est pas une décision automatique. En fin de compte, vous devez peser le pour et le contre et prendre la décision qui convient à votre situation.

Phil Patterson
la source
2
+1 Merci pour la réponse informative. J'avais vraiment du mal à accepter votre réponse ou la réponse de Deco. Finalement, parce que je ne suis pas trop expérimenté, j'ai décidé de choisir la réponse qui obtiendrait le plus de votes positifs. Je pense toujours que votre réponse mériterait plus de votes positifs. Quoi qu’il en soit, j’apprécie vraiment que vous partagiez vos connaissances et votre expérience. Je vous remercie!
BornToCode
1
Vous êtes le bienvenu! Le point principal à retenir des deux réponses est qu’il s’agit (principalement) de résoudre les problèmes de maintenance lorsque plusieurs clients doivent faire la même chose. Plus le nombre de clients utilisant le service est grand, plus le gain en maintenance est grand pour vous.
Phil Patterson
1
Il y a aussi la sécurité - les couches de service peuvent fournir un autre mur aux hackers pour qu'ils puissent accéder au trésor dans la base de données. Le manque de couches de services est peut-être la raison pour laquelle tant de sites Web ont d'énormes violations, avec un service au milieu, les pirates obtiendraient beaucoup moins de données avant d'être détectés.
gbjbaanb
6

La plupart des couches de service que j'ai vues sont un désordre complet. Les services ont tendance à avoir beaucoup de méthodes différentes, 1500 LOC ne sont pas rares. Les différentes méthodes n'ont rien en commun, mais partagent du code. Il en résulte un couplage élevé et une faible cohésion . Cela viole également OCP , car chaque fois qu'une nouvelle opération est nécessaire, vous devez modifier le code au lieu d'étendre la base de code. Une couche de service bien construite est théoriquement possible, mais je ne l'ai jamais vue en pratique.

CQRS résout ces problèmes et vous évite de créer l'une de ces couches de service procédurales.

Jeroen
la source
2
Bien construit selon les normes de qui? Certes, selon les normes OO, une interface de couche de service est l’épave d’un désordre complet. D'un point de vue fonctionnel ou procédural, cela encourage une belle approche de conception en couches. Je pense que le principal problème des utilisateurs de couches de service est qu’ils encouragent une application sans transaction et reposent sur une approche orientée objet. Je peux comprendre les deux côtés de l'argument.
maple_shaft
6

L'ajout d'une interface (une couche de service est un type d'interface) prend du temps. Un bon prend beaucoup de temps pour concevoir et tester. Il est très important de bien faire les choses du premier coup car le changer plus tard casse tous les clients. En outre, considérez que vous ne saurez probablement pas ce qui doit être dans cette interface tant que vous n’avez pas un deuxième client avec des besoins légèrement différents. Maintenir un service est un projet sans fin en soi.

Dans la plupart des organisations, si vous vous adressez à votre sponsor et demandez-leur: "Voulez-vous que les autres départements bénéficient de (réutiliser) ce système que nous développons avec votre budget?" ils vont se moquer de vous. Faites-le d'abord fonctionner pour votre sponsor, puis commencez à réutiliser ce code (sur l'heure de votre département).

Si vous savez pertinemment que la fonctionnalité que vous écrivez aujourd'hui sera réutilisée par plusieurs clients de service différents, envisagez de concevoir une couche de service dès le premier jour. Si vous n'êtes pas sûr ou s'il existe déjà de nombreuses inconnues dans le projet, commencez par travailler avec quelque chose de simple, puis séparez-le en service et client ultérieurement si vous avez le temps et le budget impartis. Il est beaucoup plus facile d’obtenir l’interface de service dès le premier essai avec un système en fonctionnement.

PS Si vous travaillez en Java, Joshua Bloch fournit de nombreux conseils en matière d’interface fantastiques tout au long de son livre Effective Java.

GlenPeterson
la source
Une excellente réponse sans théories stériles.
danilo
2

Je suis d'accord avec toi. Il n'est pas nécessaire d'inclure une couche supplémentaire si vous utilisez une seule interface utilisateur.

DAL, BL et UI / Controller sont une bonne combinaison pour concevoir une application. Si vous envisagez d'utiliser une seule interface utilisateur, il n'est pas nécessaire de préparer une couche supplémentaire. L'inclusion d'une couche supplémentaire dans l'application n'augmente que les efforts / le temps de développement.

Une autre méthode consiste à utiliser plusieurs interfaces utilisateur dans votre application. Il est bon de disposer d'une couche de service pour gérer les interfaces utilisateur dans ce cas.

Dépassement de pile: discussion sur le modèle de couche de service

Satish Pandey
la source
Donc, suggérez-vous que pour chaque application complexe, il devrait utiliser une couche de service et ne pas se contenter de couches DAL, BL, UI?
BornToCode
Dans le cas de plusieurs interfaces utilisateur, nous devons inclure une couche de service. Dans votre cas, je ne pense pas qu'il soit nécessaire de préparer une nouvelle couche. Cela ne fait qu'augmenter la complexité de l'application.
Satish Pandey
0

Je contesterais que votre BL est votre couche de service. Un lieu central où repose votre logique métier. Cela devrait être une DLL pouvant être utilisée par tout ce qui a besoin de cette logique. Ensuite, vous pouvez ajouter une couche d'API Web si votre application aura une interface utilisateur différente.

utilisateur441521
la source