Il est judicieux de séparer la façon dont les objets sont conservés de la logique métier. Si j'expose comment les objets sont conservés dans la base de données à la logique métier, alors quand je change la façon dont ces objets sont persistants, je vais devoir changer la logique métier, les rendant étroitement couplés. Cela étant dit, supposons que la logique métier utilise Foo en tant qu'objet et supposons que la couche DAL (utilisant EF) utilise FooDbModel comme objet de persistance. Construire les opérations CRUD avec le modèle de dépôt est très simple: Obtenir l'objet Foo, construire FooDbModel, faire tout ce qui est nécessaire, et construire Foo retour, et le retourner.Modèle de référentiel et fonctionnalité de recherche dans Entity Framework
Mais lorsque la fonctionnalité Find est un peu plus impliquant. Idéalement, je veux faire quelque chose comme:
Repository.Find(f => f.Name == "something");
où f est de type Foo (non FooDbModel). Est-ce possible avec EF? Je ne veux pas passer f où si est de type FooDbModel parce que c'est exposer la persistance des données au BL.
Y a-t-il un truc pour faire ça?
Projet ('Select') avant le filtre (' Où')? –
@IvanStoev Le problème avec cela est que vous devrez mettre toutes les données dans la DB en mémoire pour faire une projection. Il est similaire à Repo.GetAll(). Where (...). Ce n'est probablement pas la meilleure approche à moins que le db soit vraiment minuscule. Merci quand même. – Husain
Pas si vous le faites sur 'IQueryable'. Je ne sais pas exactement comment vos méthodes sont structurées, mais la ** implémentation ** de la méthode 'Find' que je vois est quelque chose comme' context.Set() .Select (m => new Foo {...}). (f => ...) 'qui devrait traduire en SQL. –