Personalmente me alegro de que no hay (oficial) EF equivalente de DataLoadOptions
. ¿Por qué? Un par de razones:
- Es muy fácil de utilizar de una manera que excepciones se tiran, ver la sección de observaciones del MSDN page.
- No me gusta el concepto de colecciones infantiles filtradas. Cuando un
Customer
tiene Orders
, quiero que el miembro Orders
represente las órdenes de ese cliente (flojo o no). Un filtro definido en otro lugar (por AssociateWith
) se olvida fácilmente. Los filtraré cuando y donde sea necesario. Esto lleva a la última objeción:
- Lo más importante: es stateful y la mayoría de los errores son causados por un estado inesperado.
DataLoadOptions
cambian el estado de DataContext
de manera que las consultas posteriores se ven afectadas. Prefiero definir la carga ansiosa dónde y cuándo lo necesito. Escribir es barato, los errores son costosos.
Sin embargo, para ser completo, debo mencionar que Muhammad Mosa hizo un esfuerzo en un EF version of DataLoadOptions. Aunque nunca lo intenté.
Me doy cuenta de que probablemente quiera evitar el código repetitivo. Pero si necesita consultas de forma idéntica en más de un lugar, ya está repitiendo el código, con o sin inclusiones definidas "globalmente". Una configuración central de carga ansiosa es pseudo DRY-ness. Y pronto se encontrará tropezando con sus propios pies cuando la carga ansiosa no es deseada pero, maldita sea, ¡está configurada para suceder!
Para cualquier persona que se encuentre con esto en Google: http://www.governor.co.uk/news-plus-views/2010/2/16/entityframework-include-multiple-extension-method también fue bastante útil – benjy