Je suis en train de créer un nouveau projet et de créer des objets d'affaires et de l'accès aux données, etc. J'utilise simplement des objets CLR anciens uni plutôt que des ormes. J'ai créé deux bibliothèques de classe: 1) Objets d'affaires - contient tous mes objets commerciaux, tous ces objets sont légers avec uniquement des propriétés et des règles commerciales. 2) référentiel - c'est pour tout mon accès de données.
La majorité de mes objets auront une liste des enfants dans laquelle ma question est la meilleure façon de charger des paresseux ces valeurs car je ne veux pas ramener des informations inutiles si je n'ai pas besoin de.
J'ai réfléchi lorsque vous utilisez "Get" sur la propriété enfant pour vérifier si son "null" et s'il est appeler mon référentiel pour obtenir les informations sur les enfants. Cela a deux problèmes de ce que je peux voir: 1) L'objet "sait" comment se faire passer, je préférerais qu'aucune logique d'accès à des données ne soit détenue dans l'objet. 2) Cela nécessitait les deux classes à se réfer à l'autre que dans Visual Studio jette une erreur de dépendance circulaire.
Quelqu'un a-t-il des suggestions sur la manière de surmonter cette question ou des recommandations sur la mise en page de mes projets et où elle peut être améliorée?
merci
4 Réponses :
Vous pouvez contourner le problème de la dépendance circulaire si votre code de chargement paresseux charge le référentiel de l'exécution ( activator.creeinstance ou quelque chose de similaire), puis appelle la méthode appropriée par réflexion. Bien sûr, il existe des pénalités de performance associées à la réflexion, mais elles sont souvent insignifiantes dans la plupart des solutions.
Un autre moyen de résoudre ce problème est de simplement compiler à une seule dll - vous pouvez toujours séparer logiquement vos calques à l'aide de différents espaces de noms, et organisez toujours vos classes en utilisant différents répertoires.
Pour ce faire, cela nécessite que vous programmiez des interfaces (abstractions sur les implémentations) et / ou déclarez vos propriétés virtuelles. Ensuite, votre référentiel renvoie un objet proxy pour ces propriétés qui doivent être chargées paresseusement. La classe qui appelle le référentiel n'est nulle, mais lorsqu'il tente d'accéder à l'une de ces propriétés, le proxy appelle la base de données et charge les valeurs.
Franchement, je pense que c'est la folie d'essayer de se mettre en œuvre soi-même. Il existe de grandes solutions testées à ce problème, qui ont été développées et raffinées par les plus grands esprits de .net.
Pour faire la proxy, vous pouvez utiliser Castle DynamicProxy , ou vous pouvez utiliser NHibernate et laissez-le gérer toutes les charges proxyable et paresseuse pour vous (utilisée dynamicproxy). Vous obtiendrez une meilleure performance que de toute mise en œuvre roulée à la main, garantie.
NHibernate ne gâchera pas avec vos Pocos - aucun attribut, pas de classes de base; Vous n'avez besoin que de marquer les membres virtuels pour permettre la génération de proxy.
Mettez simplement, je reconsidérerais à l'aide d'un orj, surtout si vous voulez ce chargement paresseux; Vous n'avez pas à abandonner vos pocos.
Si vous utilisez Entity Framework 4.0, vous aurez la prise en charge des POCO avec le chargement différé et vous permettra d'écrire un référentiel générique pour accéder aux données.
Il y a des tonnes d'articles en ligne sur le motif de référentiel générique avec EF 4.0
hth.
Après avoir examiné les réponses fournies et des recherches supplémentaires, j'ai trouvé un article qui utilise des délégués pour le chargement paresseux. Cela a fourni une solution plus simple que d'utiliser des proxies ou de la mise en œuvre de NHibernate.
Voici le Link à l'article.