2011-06-07 16 views
5

Tengo una pregunta muy similar a este, How do you build extensible data model, en lo que respecta a la construcción de una aplicación que utiliza un modelo de datos extensible, excepto usando EF 4.La construcción de un modelo de datos extensible, EF 4

Mi requisito es ser capaz de Permitir que los usuarios de mi aplicación extiendan el modelo de datos en tiempo de ejecución sobre la marcha. Actualmente estamos trabajando en la construcción del sistema y hemos utilizado EF como la capa DAL, con clases de POCO generadas a partir de la plantilla T4 estándar.

Respondiendo a esta publicación de Ayende, http://ayende.com/blog/3498/multi-tenancy-extensible-data-model, como un resumen conciso de las opciones, hemos tomado la opción de una columna xml en una tabla que nos permite poner casi cualquier cosa allí sin necesidad de recompilar.

Según tengo entendido, el enfoque de mesa extendida sería mejor, parece funcionar muy bien para la dinámica de CRM, sin embargo, ¿cómo/sería posible al usar EF 4 sobre la marcha?

+0

¿Cuáles son sus objetivos de diseño para estas extensiones? ¿Desea admitir la programación actual contra estas extensiones, como el soporte de CRM para proporcionar un envoltorio de servicios web fuertemente tipado que incluya propiedades extendidas, o solo necesita permitir que los usuarios almacenen datos adicionales para entidades en su modelo? La forma en que se utilizarán estas extensiones afectará la forma en que aborda el problema. –

+0

No es la programación actual como en intellisense, pero desde la perspectiva de la interfaz de usuario sí, necesitaría poder obtener una lista de las propiedades asociadas en una entidad y luego permitirle al usuario crear consultas ad-hoc contra estas. El problema con el enfoque xml es que las consultas generadas serán lentas, mientras que la división en tablas relacionales debería mejorar notablemente el rendimiento. – stu432

Respuesta

1

Una posible solución a este tipo de tareas es el patrón de EAV>http://en.wikipedia.org/wiki/Entity-attribute-value_model

+1

Esto funcionaría, no es exactamente lo que estoy buscando, intentará un método similar a este en ef (http://ayende.com/blog/4776/support-dynamic-fields-with-nhibernate-and-net-4 -0) y ver si puedo hacerlo funcionar sobre la marcha. – stu432

0

Un enfoque, he utilizado en el pasado es crear columnas genéricas, por ejemplo, int1, int2, ... intn, varchar1, varchar2, ..., varcharn etc. Esto tiene sus ventajas y desventajas. No está limpio desde la perspectiva DB (algunos DBA estarán horrorizados). Pero con SQL Severs Sparse Columns admite el almacenamiento no es un problema. Entonces puedes tener una mesa realmente amplia. Pero necesitará almacenar algunos metadatos en algún lugar como, varchar1 -> Nombre, int1 -> Edad, etc.

Ahora puede escribir consultas sql/ef normales, la búsqueda es más sencilla, SSRS es sencillo (sin análisis XML) .

También me gustaría saber si hay una solución mejor.

0

Es posible que desee ver en XML Property Promotion como una forma de acelerar el acceso a las propiedades que se han definido en el XML.

Cuestiones relacionadas