J'ai quelques tables de recherche que je suis en train de plomberie grâce à mon application. Ce sont des tables qui conduisent des listes déroulantes sur le site Web. Ils n'ont pas de logique métier, mais ils doivent passer de la base de données à l'interface utilisateur tout en suivant l'architecture de l'application.Tables de recherche - Où mettre en architecture n-Tier
L'architecture actuelle comporte une couche de données, une couche métier et une couche de présentation. Tous les appels de base de données se trouvent dans la couche de données (à l'aide d'objets de modèle et de référentiels). La couche métier appelle la couche de données et les objets BL transforment les objets de la couche de données. La couche de présentation appelle ensuite le Business Layer et utilise les Business Objects. (Fondamentalement UI -> Services -> Dépôts)
Je vois juste comme un gâchis d'avoir à plonger ceci à travers le Business Layer quand il n'y a pas de logique métier. Cela ne me dérangerait pas d'ajouter un calque de recherche, ou calque commun à cette architecture, mais je ne sais pas où il s'intégrerait ou comment j'irais incorporer dans le flux actuel. Des idées sur comment je pourrais aller à ce sujet aideraient vraiment.
EDIT: Je suppose que je voudrais vraiment savoir comment incorporer une bibliothèque commune ici afin que je puisse ajouter les recherches à cela. La bibliothèque commune devrait-elle s'interposer entre le Business Layer et l'UI, ou devrait-elle être un "remplacement" de la couche de gestion? Ou ai-je même besoin d'une bibliothèque commune?
D'accord - d'après mon expérience, les «recherches simples» ne restent souvent pas simples longtemps. Dans une version ou deux (ou sept), ils vont acquérir des cas spéciaux et des règles. Éviter la plomberie de couche d'entreprise maintenant vous achètera juste la douleur plus tard. – Bevan
+1 Oui, diviser le code en calques n'est pas toujours un gain immeadiate mais vous en serez reconnaissant. Si vous implémentez l'architecture de manière cohérente, vous devriez finir par développer des moyens efficaces de faire ces tâches de plomberie régulières - en fin de compte, il ne devrait pas être plus lent (sinon plus rapide) de faire le «long chemin». –