Migrar de 'nativo' OODBMS a ORM (Entity Framework Servidor / SQL)

Question

Hace un tiempo empezamos a desarrollar un nuevo proyecto que internamente tiene unos 25-30 diferentes clases / tipos / modelos que están muy relacionados entre sí ya sea a través de 1: n, n: m o n:. 1 las relaciones

En aquel entonces fuimos con un sistema OODBMS .net nativa, básicamente, porque lo que nos permitió hacer era tomar nuestro modelo de objeto y sólo tiene que añadir algunos métodos relacionados con la persistencia (-calls) aquí y allí y estábamos listos para ir. Sin embargo, con el tiempo nos encontramos con más y más advertencias, muy mal, no puede arreglar (en un plazo razonable) las limitaciones que nos obligó a poner en práctica soluciones lentas que resulta en problemas de rendimiento y escalabilidad mediocres en las tasas de horizonte y de licencia casi se han multiplicado por factor de 5 para nosotros sin ningún cambio en nuestro extremo (consiguieron comprados por grandes inc.).

Por lo tanto, actualmente estamos empezando a buscar una solución a largo plazo en términos de escalabilidad / rendimiento, así como el mantenimiento. Tuvimos un vistazo a otros oodbms'es "reales" y siempre encontramos con grandes interruptores para nosotros y por lo tanto empezamos a mirar un poco más allá y básicamente estamos pensando en ORM ahora, que con suerte vamos a mantener la mayor parte de la atención en nuestros objetos en lugar de discusiones con SQL.

Así que, básicamente, aquí está mi pregunta: ¿alguien tiene alguna experiencia en el mundo real con Entity Framework de Microsoft o cualquier otro ORM .NET que mantiene la configuración como de mantener como sea posible, así como un buen rendimiento en las entidades de cerca / muy relacionadas? La cantidad de datos que almacenamos no es sorprendente extensa o en cualquier tipo (se espera un total de 100 mil casos en todas las entidades dentro de los próximos 3 años).

¿Alguien tiene alguna idea / sugerencias para un ORM y / o experiencia que migran de un SGBDOO a RDBMS?

Answer 1

A medida que tiene un modelo de objetos existentes y que busca migrar a una solución ORM entonces yo diría que NHibernate sin duda sería una buena opción. He aquí por qué:

1. Usted no tendrá que hacer (m) cualquier adiciones / cambios en las clases del modelo de dominio para apoyar la persistencia. NHibernate va un largo camino hacia el apoyo de la ignorancia persistencia en el modelo de dominio, pero puedes encontrar lo que necesita hacer algunos cambios menores, tales como marcar más métodos / propiedades como virtuales de lo que de otra manera, por ejemplo.
2. Después de la cartografía de su modelo de objeto existente, se puede generar el esquema de la base de datos. Este es un gran ahorro de tiempo para el dominio impulsada (o principio sólo a objetos modelo) de desarrollo. Esta funcionalidad se admite a través del método FluentConfiguration.ExposeConfiguration () con fluidez NHibernate o por medio de la herramienta de hbm2ddl con archivos de asignación estándar NHibernate. Esto también ayuda, por supuesto, la capacidad de mantenimiento -. Cambios en el modelo de objetos se pueden reflejar de forma rápida en su esquema de base
3. Uso de fluidez NHibernate para el mapeo ayuda a hacer el mapeo inicial bastante rápido a medida que se autocompletar y un modelo simplificado de mapeo. Esto también ayudará a darle la capacidad de mantenimiento que busca - el mapeo se declara en código con fluidez NHibernate, por lo que las herramientas de refactorización va a cambiar su asignación en consecuencia. También puede encontrar que usted puede utilizar Fluido NHibernate automapping y evitar manualmente la cartografía de su modelo de objetos en su mayor parte.

El uso de Entity Framework para esto será más difícil. Mientras marco de la entidad es un ORM capaz en muchos aspectos, no es tan madura como NHibernate y hay algunas razones en este caso específicamente por eso que creo que probablemente no es la mejor opción:

1. Usted tendrá que hacer un montón de cambios en el modelo de objetos existentes para apoyar Marco de la entidad. Si desea utilizar las herramientas actualmente suministrados para marco de la entidad es probable que necesite migrar el código para las clases parciales generadas que heredan de la clase base EntityObject marco de la entidad. Este requisito herencia puede o no ser un problema para usted dependiendo de su modelo de objetos existentes. Se podría evitar esto mediante el apoyo algunas interfaces en el código, pero esto es no trivial y creo que va a perder mucho el construido en el soporte de herramientas para la gestión de sus asignaciones.
2. Es casi seguro que tenga que crear manualmente el esquema de base de datos. Con un buen modelo de objetos de tamaño esto no suele ser una tarea insignificante.
3. El marco de la entidad no soporta la carga diferida transparente de la caja. Estoy seguro de carga diferida transparente es algo que está acostumbrado con un SGBDOO, y es apoyado por la mayoría de otros (incluyendo NHibernate por supuesto), pero con marco de la entidad se encuentra que necesita objetos relacionados a explícitamente .load () ORM (ambos padres y las relaciones niño) antes de que les hace referencia en el código. Hay soluciones para este (por ejemplo, éste ), pero no es una característica incorporada.

En general, en mi opinión, para el desarrollo del primer objeto, o cuando usted está tratando de aprovechar un modelo de objetos existentes, NHibernate es una mejor opción. Para desarrollos centrados en datos, Entity Framework (o LINQ to SQL o incluso subsónica) se convierten en opciones más viables.

También es posible que desee evaluar las ofertas comerciales tales como ORM Lightspeed - I tienen poca experiencia con esta herramienta en particular a mí mismo (clientes generalmente se oponen a pagar por un ORM cuando hay buenas alternativas libres) pero está muy bien considerado.

Answer 2

No tengo ninguna experiencia con OODBMSes, pero mi experiencia con NHibernate + MS SQL Server ha sido muy positiva en cuanto a la aplicación en cascada y los cambios hacia abajo uno-a-muchos, muchos-a-uno y muchos-a muchas relaciones.

¿Qué herramienta OODBMS está usando? Podría ser posible que un SGBDOO -. Existe herramienta de migración> RDBMS, pero no estoy al tanto de cualquier