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

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.

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.

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.

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.

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.

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.

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

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.