Je concevons une couche d'accès aux données avec ADO.NET 2.0 et C #, SQL Server 2005. Je me bat souvent avec mon cerveau sur où placer ces appels. Et j'utiliserais une autre classe comme ci-dessous pour effectuer l'accès aux données de base. Comme ci-dessous Méthode 1
méthode 2
3 Réponses :
Si vous suivez le principe de séparation des préoccupations , vous irez avec votre méthode 2.
avoir des responsabilités différentes dans différentes classes permet de créer un code testable et maintenu.
Cela produit également des classes plus petites et plus cohérentes plus faciles à écrire, à la raison de l'exactitude et de vérifier l'exactitude.
Comme une note, vous pouvez utiliser un orm au lieu de la main de votre accès à la main couche.
Merci pour cette réponse, je n'ai pas beaucoup d'expérience dans l'industrie pour parvenir à une décision qui est la raison pour laquelle je l'ai dit cela. Pourriez-vous expliquer davantage sur la manière dont la méthode2 m'aidera autre que fournir sop
@DeeEptechtons - J'ai ajouté des détails supplémentaires.
Nous pourrions utiliser un orm que nous sommes d'enquête NHibernate pour le prochain projet, mais maintenant pour le projet actuel, je n'ai eu aucun choix :) merci
Je supporterais du deuxième choix, causer
unité opérationnelle
Donc, dans ce cas, vous séparez les données des fonctions qui les utilisent, rendant unantest notamment et destrant les responsabilités entre différents domaines de votre code, avec, éventuellement, des bogues faciles.
aller avec la méthode 2. Ce n'est pas la responsabilité de la classe de la société de lire / écrire à partir d'une source de données ( implémentation implémentation de l'interface. De cette façon, vous pouvez injecter l'icompanyrepository dans la classe qui doit économiser / récupérer les informations de l'entreprise. Il permet également de faciliter les tests unitaires et la possibilité de créer une implémentation différente à l'avenir (passer d'une base de données à des fichiers XML ou autre).
Yup j'utilise iCompanyRepository pour maintenir / étendre la liste des méthodes que la société peut s'étendre. Juste que trop de code n'est parfois pas nécessaire dans les questions;)
@DeeEptechtons: assez vrai;)
En fait, le code NSO est venu à l'échnologie actuelle, s'il vous plaît. C'est un irpostage
@Tomtom: Oui, je suis d'accord avec l'approche générique du référentiel (pourquoi recréer le même code chaque projet?). Jamais utilisé Lync (ou entendu parler de cela jusqu'à aujourd'hui). Il est temps d'apprendre quelque chose de nouveau!
@Tomtom: Bien que je puisse ajouter que j'essaye de tout forcer dans un référentiel à une taille unique - tous génériques n'est pas toujours l'approche à prendre. Il peut entraîner des abstractions qui fuient lorsque vous n'exigez pas tout exposé par l'interface (ou lorsque vous devez empêcher certaines méthodes (par exemple, lorsque vous ne souhaitez pas permettre d'économiser / mettre à jour car la source de données ne doit être réelle que). Utilisez un référentiel générique quand il est logique (qui est généralement ).
@Jasondown accepté comme réponse. Bien que je n'ai pas beaucoup compris les commentaires de TomTom. Cela signifie-t-il plutôt une interface pour chaque référentiel que je devrais créer quelque chose de générique?
@DeePechTons: Cela fait partie de ce qu'il disait. Voici un lien de liens pour l'expliquer plus en détail: forums.asp.net/t/ 1629771.aspx / 1 et voici un argument contre celui-ci (sans fabriquer de légères modifications): RICHARDDINGWALL.NAME/2009/01/19/...
En fait, je dis que si vous vous asseyez et que vous ne savez pas que vous n'avez pas de sens dans la programmation - un peu comme un cuisinier ayant des problèmes de fabrication d'œufs n'a pas d'avenir dans une cuisine professionnelle.
@Deeetectechtons: Voici des informations sur Lync: en.wikipedia.org/wiki/microsoft_lync
@Jason Down: En fait, désolé. Votre lien est obsolète ou Witte NBY un idiot. La prochaine fois que je vois un référentiel avec "getall" ou "getbyid" la personne est tirée et je sleeap son visage pour incompétence. LINQ a résolu ce problème pendant des années maintenant.
@Jason Down: et - votre lien vers Wikipedia est comique. Vraiment. Linq! = Lync. LINQ = Query intégré de la langue. Lync = Success à Microsoft Office Communication Server, essentiellement un système de communication. Lien totalement indépendant.
@Tomtom: Vous êtes celui qui a écrit Lync, pas Linq (dans votre premier commentaire). Je sais ce que Linq est. Je viens de fournir un lien à Lync parce que je ne sais pas ce que c'est et je n'en ai jamais entendu parler, vous l'avez apporté (et me confondez-moi et bien évidemment l'OP). Pourquoi ne cessez-vous pas d'être un imbécile et d'être utile. Fournir une meilleure réponse au lieu d'être immature.
Ouais, mais je n'ai pas lié Wikipedia ici;)