2011-05-03 13 views
12

Estoy construyendo mi solicitud Agente estación de trabajo mediante el MEF y ADO.NET Entity Framework 4.¿Cuál es la mejor manera de ordenar los datos dentro/fuera de los complementos?

La aplicación es un simple agente que se ejecuta en un ordenador con una arquitectura plug-in (y muchos complementos en forma de archivos .dll).

Cada complemento consultará su propia tabla específica del complemento. El programa maestro (o agente) necesita pasar información al complemento y recibir información del complemento.

Los plug-ins utilizarán Entity Framework 4.1 para recuperar los datos, por lo que ya tendrán los datos formateados como objetos (quizás objetos pesados ​​ya que están vinculados al contexto EF). Además, los datos que estoy retirando de la base de datos son una serie de combinaciones, por lo que los datos no coinciden con ninguna de las identidades/clases de POCO que ya había creado.

¿Cuál es la mejor manera de almacenar datos dentro y fuera de los complementos? Teniendo en cuenta que estoy usando MEF para unir las piezas, y que ya tengo objetos para los datos en los complementos. ¿Debo crear un POCO nuevo y mover los Datos de la Entidad dentro de él, luego mezclar arreglos? ¿Debo crear una lista? No solo estoy interesado en lo que se puede hacer, sino en cuáles son las mejores prácticas.

+0

¿Qué hará la aplicación con los datos que obtiene de los complementos? Supongo que es una acción predefinida, por lo que codificar contra una interfaz (una que la aplicación y el plugin conocen, tal vez en una biblioteca 'Commons' separada) tendría sentido. – Omar

+0

Gracias Omar. Me gustaría que la aplicación principal guarde el resultado generado por el complemento en una base de datos; Creo que puedo hacerlo en [Return]. Pensando más en mi pregunta, lo que realmente quiero saber es cuál es la mejor práctica para reunir datos entre las bibliotecas. Terminé creando un POCO nuevo (sin getters y setters) con solo los campos que iba a usar, agregándolos a una lista, descartando el contexto EF y devolviendo la lista. – s0ftimage

+0

Su enfoque tiene sentido para mí, aunque probablemente también habría usado un nuevo POCO (o una lista de POCO) para enviar datos al complemento. No es necesario que los complementos realmente sepan algo acerca de su capa de datos, ¿verdad? – Adventure

Respuesta

1

Este es un buen artículo en Data Transfer Objects. Toca los puntos que está trayendo aquí con los objetos POCO. Desde su construcción de una aplicación con la intención explícita de una mayor expansión y personalización, creo que los objetos POCO son el camino a seguir. De lo contrario, cualquier otro componente requerirá dependencias de EF que pueden ser engorrosas para los desarrolladores de complementos. Con los objetos POCO/DTO, tendrá mucho más control sobre lo que se envía y en qué estructuras se envía.

Los complementos deberían implementar una clase base (virtual?) O una interfaz. Probablemente elegiría la interfaz porque, de nuevo, será más fácil para los desarrolladores de complementos agregar una interfaz a su código que una clase base.

Realmente, no digo nada nuevo que usted, Omar y Aventura no hayan dicho todavía. Básicamente, estoy diciendo que creo que ya tienes un buen manejo :)

+0

gracias Jeff! Leí el artículo. – s0ftimage

Cuestiones relacionadas