Dans EF 4.1, puis-je avoir DBSet <ISomething> au lieu de DBSet <Something>?

Question

J'essaye de construire un modèle de domaine avec des méthodes d'affaires et ai EF 4.1 faisant la persistance pour moi. Jusqu'ici tout va bien.

Le problème est, toutes les propriétés sont exposées en tant que public sur mes classes de domaine. C'est au moins ce que j'ai appris du tutoriel de toute façon. Cela signifie que je n'ai aucune preuve solide que les propriétés de classe ne seront pas modifiées par certains programmeurs imprudents en dehors des méthodes commerciales. Encapsulation violée.

J'ai essayé d'introduire quelque chose mais TableAttribute ne s'applique qu'aux classes, pas aux interfaces, donc je ne peux pas dire à EF de faire DBSet. Si je laisse TableAttribute aux classes mais que je fais quelque chose implémenter quelque chose ISomething alors je ne peux pas faire DBSet.Add() car EF ne connait pas quelque chose. La seule façon que je peux penser est d'écrire une couche d'abstraction complète sur EF 4.1 pour CRUD en utilisant des interfaces. Sous le capot, faites la traduction de type entre quelque chose et quelque chose. Cela a semblé beaucoup de complexité et un trou béant dans le design d'EF. Ou j'ai dû manquer quelque chose.

Comment voulez-vous résoudre ce problème?

Merci beaucoup.

Answer 1

Le problème est, toutes les propriétés sont exposées en tant que public sur mes classes de domaine. C'est au moins ce que j'ai appris du tutoriel de toute façon. Cela signifie, je n'ont aucune preuve solide que les propriétés de classe ne changeront pas par certains programmeurs négligents en dehors des méthodes commerciales. L'encapsulation a été violée.

Comment cela va être résolu par l'interface? L'interface exposera à nouveau toutes les propriétés en tant que public et EF demande que la propriété doit avoir getter et setter.

EF n'est pas capable de fonctionner avec des interfaces. Lorsque vous utilisez EDMX pour le mappage, il est possible de jouer un petit peu avec l'accessibilité des propriétés, mais lorsque vous utilisez du code, c'est d'abord pire car le mappage est affecté par les mêmes règles d'accessibilité. Créer une couche d'abstraction au-dessus de EF est la même chose que de ne pas utiliser EF du tout. Une fois que vous avez créé l'abstraction, vous ne pouvez pas utiliser linq-to-entities directement et vous perdrez la raison principale pour utiliser EF.

Votre problème est plus sur: Où est la limite? Si vous voulez travailler avec des entités uniquement dans des méthodes métier, vous ne devez pas les exposer à ces méthodes. Si vous voulez vous assurer que les propriétés sont correctement traitées, vous devez peut-être implémenter une logique de validation directement dans l'entité.