J'ai commencé à créer une application en 3 couches (DAL, BL, UI) [elle gère principalement le CRM, certains rapports de vente et l'inventaire].
Un collègue m'a dit que je dois passer au modèle de couche de service, que les développeurs sont venus au modèle de service à partir 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 rendre les choses plus complexes et je ne voyais pas grand-chose qui pourrait justifier cela.
Cette application a une petite interface utilisateur partielle supplémentaire qui utilise certaines (mais seulement quelques-unes) des fonctions de l'application de bureau, donc je me suis retrouvé à dupliquer du code (mais pas beaucoup). Juste à cause de la duplication de code, je ne le convertirais pas en service, mais il a dit que je devrais l'utiliser quand même 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 google dessus, mais je suis toujours confus et je ne peux pas décider quoi faire.
Le livre de Martin Fowler "Patterns of Enterprise Architecture" déclare:
La question la 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 n'aura qu'un seul type de client - disons, une interface utilisateur - et 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 avantageux de concevoir une couche de service dès le début.
Les avantages d'une couche de service sont 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. Lorsque vous avez une application qui a plus d'un type de client qui utilise sa logique métier et a des cas d'utilisation complexes impliquant plusieurs ressources transactionnelles - il est logique d'inclure une couche de service avec des transactions gérées.
Avec CRM, Sales and Inventory, il y aura beaucoup de cas d'utilisation de type CRUD dont il y aura 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 atomiquement par les opérations de la couche de service.
Un autre avantage d'avoir une couche de service est qu'elle peut être conçue pour un appel local ou distant, ou les deux - et vous donne la flexibilité de le faire. Le modèle jette les bases de l'implémentation encapsulée de la logique métier d'une application et de l'appel de cette logique par divers clients de manière cohérente. Cela signifie que vous réduisez/supprimez également la duplication de code, car vos clients partagent les mêmes services communs. Vous pouvez également potentiellement réduire les coûts de maintenance - car lorsque votre logique métier change, vous n'avez (généralement) besoin que de changer le service, et non chacun des clients.
En résumé, il est bon d'utiliser une couche de service - plus encore, je pense que dans votre exemple, vous avez fourni car il semble que vous ayez plusieurs clients de logique métier.
Ajouter une couche de service parce que vous avez évalué l'idée et conclu que c'est la meilleure approche: bon
Ajouter une couche de service parce que c'est ce que font tous les enfants sympas: 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 est devenu énormément axé sur la mode, les gens suivant les tendances et les bandwagons comme s'ils étaient 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 ou de bien avec une couche de service - c'est une approche particulière dont l'adéquation 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.
De nombreux facteurs entrent en jeu dans la décision de créer une couche de service. J'ai créé des couches de service dans le passé pour les raisons suivantes.
Cas 1: vous créez une fonctionnalité de base qui doit être utilisée par une myriade de clients différents. La couche de service intègre des fonctionnalités permettant à différents clients de tirer parti de vos fonctionnalités fournies dès la sortie de la boîte.
Cas 2: vous hébergez normalement du code dans l'espace d'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, toute votre organisation peut l'utiliser à partir de leurs applications sans avoir à acheter une licence pour chaque hébergement individuel.
Cas 3: vous créez des fonctionnalités permettant à des tiers de 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 expéditions de produits entrantes.
Cas 4: Vous avez analysé votre code à l'échelle de l'entreprise et constaté que des équipes distinctes ont créé la même chose (juste implémenté légèrement différemment). Avec une couche de service, vous pouvez choisir la ou les meilleures approches et vous pouvez désormais implémenter le processus de la même manière dans toutes les équipes en les faisant appeler au service. Un autre avantage de la centralisation de la logique est la détection de bogues. Vous pouvez maintenant déployer le correctif une fois et tous les clients bénéficient de l'avantage en même temps.
Cela étant dit, une couche de service présente des inconvénients potentiels.
Le point principal est que ce n'est pas toujours un slam dunk pour orienter votre système vers le service. 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. À la fin de la journée, vous devez peser le pour et le contre et prendre la décision qui convient à votre situation.
La plupart des couches de service que j'ai vues sont un gâchis 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 une forte couplage , faible cohésion . Il 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 dans la pratique.
CQRS résout ces problèmes et vous évite d'avoir à créer l'une de ces couches de service procédurales.
L'ajout d'une interface (une couche de service est un type d'interface) prend du temps. Un bon prend beaucoup de temps à concevoir et à tester. Il est très important de bien faire les choses dès le premier essai car le changer plus tard interrompt tous les clients. En outre, considérez que vous ne saurez probablement pas ce qui doit être dans cette interface jusqu'à ce que vous ayez un deuxième client avec des besoins légèrement différents. Le maintien d'un service est un projet sans fin en soi.
Dans la plupart des organisations, si vous vous adressez à votre partenaire commercial et leur demandez: "Voulez-vous que d'autres services bénéficient (réutilisent) de ce système que nous développons avec votre budget?" ils se moqueront de vous. Faites-le fonctionner d'abord pour votre partenaire commercial, puis commencez à vous débrouiller avec la réutilisation de ce code (sur le temps de votre département).
Si vous savez, pour un fait, que la fonctionnalité que vous écrivez aujourd'hui sera réutilisée par plusieurs clients de service différents, alors envisagez de concevoir une couche de service dès le premier jour. Si vous n'êtes pas sûr, ou s'il y a déjà de nombreuses inconnues dans le projet, faites d'abord quelque chose de simple et séparez-le en service et client plus tard si vous avez le temps et le budget. Il est beaucoup plus facile d'obtenir l'interface de service dès le premier essai lorsque vous démarrez avec un système fonctionnel.
P.S. Si vous travaillez en Java, Joshua Bloch a beaucoup de conseils d'interface fantastiques tout au long de son livre, Effective Java.
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 prévoyez 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 ne fait qu'augmenter les efforts/le temps de développement.
Un autre schéma consiste à utiliser plusieurs interfaces utilisateur dans votre application, il est bon d'avoir une couche de service pour gérer les interfaces utilisateur dans ce cas.
Débordement de pile: discussion sur le modèle de couche de service
Je contesterais que votre BL est votre couche de service. Un endroit central où se situe votre logique métier. Cela devrait être un DLL qui peut être utilisé par tout ce qui a besoin de cette logique. Ensuite, vous pouvez mettre une couche d'API Web en plus si votre application aura des interfaces utilisateur différentes.