J'ai une question à laquelle je n'ai tout simplement pas envie de trouver une réponse satisfaisante pour, que ce soit, soit que je ne cherche pas au bon endroit.
Notre système a été construit à l'origine avec .NET 1.1 (Toutefois, les projets prennent maintenant en charge 3.5) et toutes les entités sont persistées dans la base de données à l'aide de procédures stockées et à un "SQLHelper" qui possède les méthodes de type Standard ExecuTereader, ExecuTrenronQuery Type. P>
Donc, ce qui se passe généralement est que nous aurons nos entités par exemple, utilisateur et rôle et nous aurons une autre classe appelée usersio qui persiste les objets à la base de données avec des méthodes telles que: P>
User.Save()
5 Réponses :
Il s'agit d'un modèle commun d'avoir un référentiel distinct du modèle. Le nom IO est unique pour un tel motif mais valide. Maintenant, selon lesquelles vous parlez (TDD Nuts vous vient à l'esprit), vous risquez d'utiliser une classe statique.
Si vous recherchez des modèles de cartographie relative à des objets, vous pouvez regarder:
Il y a aussi une liste plus longue ici: http://en.wikipedia.org /wiki/list_of_Object-Relational_Mapping_software#.net
comme pour la question générale de la façon de concevoir un modèle d'objet pour la persistance, Une grande partie du choix de conception dépend de la complexité du système, l'extensibilité dont vous avez besoin, que vous devez prendre en charge plusieurs persévérances. Magasins (SQLServer, Oracle, Système de fichiers, etc.), etc. Le modèle que vous décrivez ressemble à un DataSferObject (DTO) . C'est un design commun pour séparer la logique de persévérance de la logique d'entreprise.
En tant que de côté, un principe général de bonne conception du système est le Principe de responsabilité unique . Lors de la construction d'un système, vous devez décider s'il est logique de combiner différentes responsabilités en une seule classe. La combinaison des responsabilités peut souvent compliquer un système et créer des conflits de conception difficiles à résoudre.
Vous remerciant d'avoir mis un nom sur une description plutôt longue de toute longue durée :). Pensez-vous que le type de modèles de cartographie que vous avez décrits conviennent à la fin d'un cycle de vie de produits (comme dans mon cas) ou sont-ils plus adaptés à la mise en place de développement?
Ça dépend. Certaines bibliothèques sont meilleures au travail avec les POCOS, d'autres ne le sont pas. Les bibliothèques qui exigent que le consommateur implémente de nombreuses interfaces ou hériter de classes de base spécifiques est clairement plus difficile à introduire dans un projet tard dans le jeu. NHibernate, par exemple, est relativement bon au travail avec Pocos - afin que vous puissiez peut-être l'utiliser même tard dans un projet. Cependant, garder à l'esprit - il y a quelque chose à dire pour la cohérence de la mise en œuvre. Avoir de multiples façons différentes de persister les données dans une application peut ne pas être propice à la maintenance à long terme ou au développeur à l'embarquement.
J'ai utilisé avec succès l'entité Framework 3.5. Il y en a quelques-uns, à qui je serais caractérisé en tant que puristes, qui estimaient que l'entité cadre a violé un ensemble de règles et ne devrait pas être utilisé.
À mon avis, les seules règles qui comptent sont les vôtres. Je vous recommande de commencer à expérimenter avec l'entité Framework 3.5, puisque vous l'avez maintenant. En outre, dès que vous le pouvez, vous (et à peu près tout le monde) doit commencer à expérimenter .net 4.0. Le candidat de la libération est disponible gratuitement, il n'y a donc aucune raison de ne pas au moins savoir ce qui est disponible.
Il est possible que vous puissiez vous trouver comme les changements d'EF dans 4.0 Tellement que vous voudrez attendre. Il est tout aussi probable que vous ne ressentirez pas besoin d'attendre et que vous pouvez aller de l'avant et profiter de EF tel qu'il est en 3.5. J'ai, et je suis très content de ne pas attendre.
Merci c'est de bons encouragements à ne pas ignorer complètement EF. Vous avez voulu regarder la RC comme avec tout cependant qu'il trouve le temps! Diriez-vous que EF convient à l'arrivée à côté de notre accès de données existant? Ma question pour vous est très similaire que celle de @lbushkin. Merci
@MredMundo: J'ai utilisé avec succès EF 3.5 dans les applications de production. Il y a très peu de problèmes avec cela, et ils sont assez petits, à mon avis.
Avoir un ensemble de classes qui implémentent les fonctions de données est souvent appelée programmation à plusieurs niveaux. ( http://fr.wikipedia.org/wiki/n-titier ). En séparant les classes qui accèdent au niveau de données, vous créez un système beaucoup plus maintenu. Si vous fusionniez ces fonctions dans les classes qui mettent en œuvre les règles commerciales de votre application, vous perdrez de nombreux avantages d'avoir une conception à plusieurs niveaux.
Avoir les fonctions d'accès aux données Spit dans leurs propres cours est bonne (3 acclamations pour le concepteur), cependant les avoir répandu sur tout le lieu est mauvais. Idéalement, vous ne feriez pas la source de ces fonctions pour tous être dans le même répertoire ou le même fichier (en fonction de la taille du projet). S'ils sont tous ensemble, vous gagnez de nombreux avantages. Les avoir divisés dans (aléatoire?) De nombreux emplacements défaient le but de modéliser ce code.
Un modèle que j'utilise assez régulièrement est: Chaque objet a ce qui suit:
Ce dernier peut être fait de 2 façons. Vous pouvez avoir une grande classe de référentiel, qui convient aux applications / composants avec seulement quelques objets, ou vous pouvez avoir des référentiels distincts pour chaque objet.
Jetez un coup d'œil au blog de Rudy Lacovaras. Il a récemment fait une série de messages sur un accès efficace des données à l'aide d'un modèle similaire.