Quelle couche doit contenir des interactions avec des ressources externes ou distantes qui ne sont pas des opérations de données strictement?
Supposons une application avec une architecture en couches, c'est-à-dire une présentation, entreprise/domaine/logique, accès aux données: il est logique de brancher l'accès à des API externes dans la couche de données si ce à quoi elles ressemblent à des opérations de données. Par exemple, a DLL qui effectue simplement des opérations de crud contre un référentiel de données particulier irait dans la couche d'accès aux données.
Ce que je suis un peu confus, c'est où incorporer des actions qui non Effectuer des opérations de données au sens strict, c'est-à-dire qu'ils effectuent des opérations quelque peu ressemblant à des "données" dans un sens plus lâche parce qu'ils travaillent sur des ressources à distance ou en réseau. Voici quelques exemples:
- un service Web qui télécharge A PDF d'un rapport SQL Server Reporting Services (SSRS).
- une bibliothèque qui envoie un courrier électronique via SMTP ou se connecte à une boîte aux lettres Microsoft Exchange et télécharge des messages dans une structure de dossier
- interactions directes avec le système de fichiers, telles que l'écriture dans un fichier journal, en utilisant une fonctionnalité de langage de programmation intégrée
Je suis tenté de les mettre dans la couche de données puisque beaucoup de ressources que j'ai lues indiquent cela. Par exemple, Cet article MSDN sur "Directives de la couche de données" a à la fois des "sources de données" et "Services" suspendus à la couche de données et indique "les services" ":
Lorsqu'un composant métier doit accéder aux données fournies par un service externe, vous devrez peut-être implémenter le code pour gérer la sémantique de communiquer avec ce service particulier. Les agents de service mettent en œuvre des composants d'accès aux données qui isolent les exigences variables pour appeler des services à partir de votre application et peuvent fournir des services supplémentaires tels que la mise en cache, la prise en charge hors ligne et la mappage de base entre le format des données exposées par le service et le format de votre application.
Toutefois, cela parle de services externes qui effectuent spécifiquement des opérations de données et ne mentionne aucune mention des autres types d'opérations de type quelque peu de données telles que j'ai énuméré ci-dessus.
L'alternative consiste à les mettre dans la couche logique de l'entreprise ou de domaine, mais il ne se sent pas dû à d'accéder à des ressources réseau externes ou de serveur, telles que celle-ci à partir de la couche logique Business ou Domaine.
Quelqu'un peut-il offrir des conseils ou certaines de leurs expériences sur ce sujet?
On dirait que vous décrivez le Architecture d'oignon , une forme d'architecture N-Tier - qui est juste une façon fantaisie de dire que les composants ont éclaté dans des couches.
La couche que vous concentrez sur est l'infrastructure couche. Les données sont la composante la plus courante de l'infrastructure. Mais d'autres fonctions peuvent être contenues dans des bibliothèques distinctes dans la même couche.
L'architecture est une chose subjective. Le mieux que je puisse faire est de vous offrir comment je voudrais mettre en place le projet.
Si vous souhaitez être vraiment explicite sur vos couches, vous pouvez utiliser des dossiers de solution pour séparer les choses.
Avis que je n'ai pas inclus le dossier de solution dans l'espace de noms - c'est Whatever.Web, ne pas Whatever.Client.Web. C'est un autre appel subjectif, mais je l'ai trouvé plus propre de cette façon. Les dossiers de la solution ne sont obligés de faire partie de l'espace de noms comme les dossiers de projet sont.
Et à la fin, une fois que j'avais une intuition pour quelles préoccupations appartiennent à la couche, j'ai trouvé que je n'avais même pas vraiment besoin des dossiers de solution:
Juste en jetant un coup d'œil à cela, il est clair pour moi que les modèles partagés sont dans le noyau, le client est le Web, et tout le reste est là pour soutenir comme infrastructure. Mais si j'ai commencé à obtenir de nombreux autres projets dans chaque couche, je pourrais alors revenir à l'organisation avec des dossiers de solution.
Pour un crédit supplémentaire, je pourrais mentionner que personnellement, ma couche principale/domaine aurait des interfaces pour les services d'infrastructure:
Et la bibliothèque d'infrastructures mettrait ensuite en œuvre cette interface, vous pouvez donc toujours "échanger" la dépendance, quelle que soit votre implémentation de la bibliothèque.
Je pense que vous êtes extrapolé de la terminologie plutôt ancienne de la "couche de données" et de "couche d'accès aux données"
L'hypothèse implicite de ces termes est que vous disposez d'une grande base de données que votre application est désactivée et que vous souhaitez séparer et résumé de vos applications ou "couche d'entreprise". Vous voulez éviter de polluer votre "devrait être disponible pour toutes les utilisations, des données présentes et futures, des données" avec votre "logique commerciale de la journée"
Mais vous, par exemple, des cas sont un peu plus modernes dans leur pensée, reliant divers "services" qui fournissent des fonctionnalités aléatoires à l'appelant.
La réponse est que votre "couche d'entreprise" est toujours roi. Il devrait consommer des services, dont certains sont votre "couche d'accès aux données" traditionnelle, mais le fait même que vous résumez cette couche signifie que la couche d'entreprise ne sait pas que ce service est dans la couche de données.
Il pourrait s'agir simplement d'encapsulé dans la logique de mémoire qui fait également partie de votre couche d'entreprise, il pourrait s'agir d'une tierce partie externe ou d'un système de fichiers local.
Ok ... une réponse simple. Lorsque je construis un projet qui possède un comportement "perpendiculaire" (connexion à des systèmes externes, écrire aux fichiers journaux, etc.) Je le fais via une bibliothèque et effectuez généralement les appels dans la couche d'entreprise. La couche d'entreprise est typiquement lorsque l'action nécessitant un accès externe est en cours et en renforçant la capacité dans une bibliothèque, je peux la réutiliser dans d'autres projets. Les bibliothèques sont bonnes. Gardez vos contrôleurs dans la couche d'entreprise simple et poussez les trucs étranges dans les bibliothèques ou autrement que vous serez déclenché plus tard.
Quand j'ai besoin de faire quelque chose qui est non-cache-couche ressemble à -couche de données C'est généralement une odeur de code indiquant que je devrais vraiment mettre le code dans une bibliothèque, ou c'est juste quelque chose que je piste temporairement.
Eh bien, il n'y a pas de réponse générique, pour certains c'est une question d'opinion, donc je ne répondrai pas de manière générique, mais je prendrai vos points un par un. Je réponds compte que tous ceux-ci seront conçus comme une interface simple. Pas la mise en œuvre.
un service Web qui télécharge A PDF d'un rapport SQL Server Reporting Services (SSRS).
Cela pourrait être juste une partie d'une classe UTIL appelée dans la couche d'entreprise. Ou si vous considérez un peu plus large, il s'agit de lire des fichiers, qu'ils soient éloignés ou non. C'est juste un accès de données imo. Seul la mise en œuvre (non test :)) le rendra à distance.
une bibliothèque qui envoie un courrier électronique via SMTP ou se connecte à une boîte aux lettres Microsoft Exchange et télécharge des messages dans une structure de dossier
Donc, il s'agit de lire ou d'écrire dans une boîte aux lettres? Quelle est la différence avec une lecture/écriture dans une base de données? La réponse est la mise en œuvre. Donc, la lecture/écriture brute n'est que l'accès des données. Bien sûr, analyser le fichier pour générer des données ou choisir ce qu'il faut placer dans le fichier à envoyer appartient à la couche d'entreprise.
Et puisque vous avez à la fois SMTP/MicroSoft Exchange, vous auriez 2 implémentations différentes. Les affaires vont dire lequel il veut utiliser.
interactions directes avec le système de fichiers, telles que l'écriture dans un fichier journal, en utilisant une fonctionnalité de langage de programmation intégrée
Encore une fois, cela concerne le stockage, la lecture/écriture d'accès des données. Dans mon cas, j'ai FileService qui peut enregistrer n'importe quel fichier sur le système et renvoyer un fichier FileInfo stocké dans la base de données, un objet peut donc être lié au fichier.