Qu'est-ce que les habitudes alternatives d'utilisation du cadre d'entité?
Certa Certas je sais sont:
"plaine" EntityFramework - AKA Unity of Work
motif de référentiel
5 Réponses :
Nous utilisons le code similaire à ce que vous avez dans votre unité de travail.
Ce que nous faisons en outre est de mapper des objets aux objets de transfert de données.
Un bon livre à regarder est Martin Fowler's " Motifs de l'architecture d'applications d'entreprise ".
Là, il passe par des modèles de récupération / cartographie des données telles que DTOS, unité de travail, motif de référentiel, etc. Peut-être que quelque chose pourrait être utile avec le cadre d'entité. Je devrais y jeter un coup d'oeil.
Il existe de nombreux articles sur le sujet, mais la liste sera considérablement réduite si vous l'souhaitez un bon. Cet article du magazine MSDN est plutôt bon, bien que cela traite spécifiquement des applications N-TIER. Mais puisque vous ne dites pas ce que vous construisez, peut-être que cela aidera.
LINQ 2 SQL peut être une alternative. Voici un article Injection de dépendance avec unité et Linq à SQL Datacontexts
Unity - http://unity.codeplex.com/
Je réponds à votre question en fonction de l'hypothèse que vous utilisez un cadre d'entité directement dans votre interface utilisateur / contrôleur / services.
Il a été prouvé que l'utilisation de tout ORM, incluse EF, directement dans votre interface utilisateur / contrôleurs / services. causer beaucoup de problème à l'avenir. En plus de cela, cela le rend si difficile, voire impossible, de tester votre application.
La deuxième approche, c'est-à-dire "Le modèle implémentant un référentiel" est également faux à mon avis, car le modèle et les répulsions de Becuase ont différents Responsabilités et basé sur une partie "Responsabilité unique" des principes solides, vous ne devez pas fusionner les deux concepts ensemble. Même si vous souhaitez utiliser des objets actifs dans votre modèle, je ne le recommande pas, vous devez découpler votre modèle de l'ORM que vous utilisez.
La solution la mieux et la plus recommandée consiste à avoir une interface comme un irexuel ou un irpostage avec les membres très basiques comme le suggèrent. Quelque chose comme: Notez que certains référentiels de biais de poisson ne doivent pas retourner iquéryable. De plus, vous pouvez envisager d'utiliser l'ispécification au lieu d'expressions et de Lambda. Vous devez mettre en œuvre une interface IREPOSITOY pour la plupart de vos entités. En utilisant cette approche, vous pouvez également vous moquer de vos référentiels lorsque vous écrivez des tests unitaires. En production, vous auriez besoin d'utiliser un fournisseur de CIO, tel que l'unité, Ninject, Linfu, Cattsle et etc., vous pouvez également bénéficier de la mise en œuvre de la localisation de service commune de Microsoft afin d'éviter le couplage à un cadre spécifique IOC. in Les anciens jours, j'avais l'habitude d'avoir une interface d'accès aux données qui a été implantée pour un domaine commercial spécifique ou un service. L'une des questions de cette approche est que vous vous retrouveriez avec du code en double dans différents services d'accès à des données si vous gardez une trace de votre code source et vous finirez par.
Je recommanderais de changer le titre de la question parce que c'est un peu déroutant. Le titre indique comment utiliser l'ensemble de l'entité et toute la discussion sur les alternatives (c'est-à-dire comment ne pas l'utiliser)
pas vraiment. J'essaie d'obtenir des moyens comment utiliser EF exactement. Je veux dire que je n'ai pas besoin d'alternative pour EF, j'ai besoin d'une manière possible d'utiliser - des modèles différents basés sur EF.