Patrón de repositorio con carga diferida usando POCO

Question

Estoy en el proceso de iniciar un nuevo proyecto y crear los objetos comerciales y el acceso a los datos, etc. Solo estoy usando objetos simples antiguos clr en lugar de cualquier orms. Creé dos bibliotecas de clases: 1) Business Objects: contiene todos mis objetos comerciales, todos estos objetos son livianos y solo tienen propiedades y reglas comerciales. 2) Repositorio: esto es para todos mis datos de acceso.

La mayoría de mis objetos tendrán lista de niños y mi pregunta es cuál es la mejor manera de cargar estos valores perezosos ya que no quiero traer información innecesaria si no la necesito.

He pensado en utilizar el "obtener" en la propiedad secundaria para comprobar si es "nulo" y si es llamar a mi repositorio para obtener la información del niño. Esto tiene dos problemas por lo que puedo ver: 1) El objeto "sabe" cómo obtenerlo. Prefiero que no se tenga ninguna lógica de acceso a datos en el objeto. 2) Esto requirió que ambas clases se refirieran entre sí, lo que en el estudio visual arroja un error de dependencia circular.

¿Alguien tiene alguna sugerencia sobre cómo superar este problema o cualquier recomendación sobre el diseño de mis proyectos y dónde se puede mejorar?

Gracias

Answer 1

Después de examinar las respuestas proporcionadas y buscar más, encontré un artículo que usa delegados para la carga diferida. Esto proporcionó una solución más simple que usar proxies o implementar NHibernate.

Aquí está el link para el artículo.

Answer 2

Puede moverse por la cuestión de la dependencia circular si su código de carga diferida carga el depósito en tiempo de ejecución (Activator.CreateInstance o algo similar) y luego llama al método apropiado a través de la reflexión. Por supuesto, hay penalizaciones de rendimiento asociadas con la reflexión, pero a menudo resultan insignificantes en la mayoría de las soluciones.

Otra forma de resolver este problema es simplemente compilar a un único dll; aquí aún puede separar lógicamente sus capas usando diferentes espacios de nombres, y aún organizar sus clases usando diferentes directorios.

Answer 3

Para hacer esto, se requiere programar las interfaces (abstracciones sobre implementaciones) y/o declarar sus propiedades virtuales. Luego, su repositorio devuelve un objeto proxy para aquellas propiedades que se deben cargar de forma perezosa. La clase que llama al repositorio no es la más acertada, pero cuando intenta acceder a una de esas propiedades, el proxy llama a la base de datos y carga los valores.

Francamente, creo que es una locura intentar implementarlo. Existen excelentes soluciones comprobadas a este problema que han sido desarrolladas y refinadas por las mentes más brillantes de .NET.

Para realizar el proxy, puede usar Castle DynamicProxy, o puede usar NHibernate y dejar que maneje todo el proceso y la carga diferida para usted (usa DynamicProxy). Obtendrá un mejor rendimiento que con cualquier implementación enrollada a mano, garantizada.

NHibernate no se meterá con tus POCOs - sin atributos, sin clases base; solo necesita marcar miembros virtuales para permitir la generación de proxy.

En pocas palabras, reconsideraría el uso de un ORM, especialmente si desea esa carga diferida; no tiene que renunciar a sus POCO.

Answer 4

Si está utilizando Entity Framework 4.0, tendrá soporte para POCO con carga diferida & le permitirá escribir un repositorio genérico para hacer acceso a los datos.

Hay toneladas de artículos en línea sobre el patrón de repositorio genérico con EF 4.0

HTH.