Besoin de conseils concernant la solution en couches, la séparation des problèmes, etc.

Question

Nous avons une application en couches, ou du moins nous sommes en train de la passer à une, comme suit:

• Interface (interface utilisateur ou application, par exemple, service Web, etc.)
• logique métier
• Accès aux données

Pour rendre le reste de cette question plus concret, je vais décrire un cas spécifique.

Nous avons une interface utilisateur qui contient un objet contrôleur (la couche de logique métier). Ce contrôleur communique avec la base de données via un autre objet (la couche d'accès aux données).

Dans un contexte donné, l’interface utilisateur permet à l’utilisateur de choisir un employé auquel l’opération sera liée. Puisqu'il existe des règles concernant les employés que l'utilisateur peut choisir (enfin, tout monde extérieur au contrôleur), le contrôleur fournit deux choses à cet égard:

• propriété lisible contenant une liste d'employés disponibles parmi lesquels choisir
• une propriété en lecture / écriture contenant l’employé actuellement choisi

L’interface utilisateur peut lire la liste et l’utiliser pour renseigner une liste déroulante.

Dans la version 1 de cette application, la liste déroulante contient le numéro d'identification de l'employé + le nom de l'employé.

Tout va bien ...

... jusqu'à la version 1.1, un correctif. Un utilisateur se plaint de ne pas pouvoir choisir entre Jimmy Olson et Jimmy Olson car l'application ne lui permet pas assez de savoir lequel est lequel. Il sait qu'il y a un Jimmy dans le département des ventes et un autre dans le département du développement. Le correctif de cette version 1.1 consiste donc simplement à ajouter une barre oblique + le nom du département dans la liste déroulante. Dans la version 2, nous opterions pour le remplacement de la liste déroulante par une liste déroulante avec support de colonne, supprimant la barre oblique, mais dans la version 1.1, cette option est choisie pour réduire le risque de nouveaux bugs.

En d'autres termes, la liste déroulante contiendrait:

• 1 - Jimmy Olson / Ventes
• 2 - Jimmy Olson / Développement
• • autres personnes

Cependant, le code de l'interface utilisateur n'a pas de code SQL, ni aucun moyen de contacter ce département. Nous devons donc aller voir le contrôleur et y regarder le code. Le responsable du traitement n'a pas besoin du service, et pour être honnête, il n'a même pas besoin du nom de l'employé; le numéro d'identification suffit, il n'y a donc rien dans le responsable qui demande ou fait quoi que ce soit au service. Nous devons donc descendre à la couche d’accès aux données et changer le code SQL.

Cette solution sent très franchement.

S'il existe plusieurs interfaces avec ce contrôleur, avec des exigences différentes, nous avons trois solutions possibles:

1. Modifiez la couche d'accès aux données afin de répondre aux besoins (croissants / divers) de plusieurs interfaces (2 couches plus loin), ce qui signifie que toutes les interfaces obtiendront éventuellement toutes les données dont elles ont besoin, mais qu'elles en obtiendront également. requis pour l'une des autres interfaces
2. Ajoutez quelque chose qui permet à l'interface utilisateur d'indiquer à la couche d'accès aux données (toujours à 2 couches) ce dont elle a besoin
3. Faites en sorte que la couche d'interface utilisateur récupère les données requises sans changer ni le contrôleur ni la couche d'accès impliquée, cela semble indiquer que nous avons besoin de plus de code d'accès aux données, quelque part.

Aucune des solutions ci-dessus ne semble satisfaisante.

Ce que je me demande, est-ce que nous sommes complètement hors de cours? Comment ferais-tu ceci? Y a-t-il une quatrième et une cinquième solution en dessous des 3 ci-dessus?

Selon cette question: Séparation des problèmes , la réponse acceptée contient la citation suivante:

  

La séparation des préoccupations garde le code séparé pour chacune de ces préoccupations. La modification de l'interface ne nécessite pas de modification du code de la logique applicative, et inversement.

Cela signifie-t-il simplement que toute la couche d'accès contrôleur / données

Answer 1

Comme je le vois, vous avez deux possibilités:

1. Les couches inférieures envoient-elles tout l'information qu'ils ont sur un personne, éventuellement sous forme de document XML, même si beaucoup de consommateurs de cette information n'a pas besoin de tout.
2. Fournir des API pour le niveau supérieur couches pour creuser et obtenir le informations dont ils ont besoin. Donc dans le Si vous donnez, avez une méthode qui l'interface peut demander à l'entreprise couche à demander à la couche de base de données pour le département ayant l'identifiant de l'utilisateur.

Les deux font des compromis. Le premier expose beaucoup plus d'informations, éventuellement aux consommateurs qui n'ont aucun droit sur ces informations. Le second transmet beaucoup moins d’informations par transaction, mais nécessite plus de transactions. Le premier ne nécessite pas de modification de l'API chaque fois que vous avez plus d'informations, mais modifie le code XML. La seconde conserve l'interface des API existantes, mais fournit de nouvelles API au fur et à mesure de l'évolution des besoins. Et ainsi de suite.