c# - developer - entity framework
¿Están todos aquí saltando en el carro de la banda ORM? (19)
He estado en el tren ORM por más tiempo, desde la versión gratuita de LLBLGen hasta el último y más grande producto comercial LLBLGen Pro. Creo que los ORM se adaptan muy bien a muchos de los sistemas de salida de entrada de datos comunes.
Eso no quiere decir que resuelvan todos los problemas sin embargo. Es una herramienta que se puede usar donde tenga sentido usarla. Si su esquema de base de datos está relativamente cerca de cómo deben ser sus objetos comerciales, los ORM son los mejores.
Microsoft Linq to SQL, Entity Framework (EF) y nHibernate, etc. están proponiendo ORMS como la próxima generación de tecnologías de mapeo de datos, y afirman ser livianas, rápidas y fáciles. Como por ejemplo este artículo que acaba de ser publicado en la revista VS:
http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583
¿Quiénes están entusiasmados con la implementación de estas tecnologías en sus proyectos? ¿Dónde está la innovación en estas tecnologías que las hace tan buenas con respecto a sus predecesoras?
He estado siguiendo a Fluent-NHibernate muy de cerca ya que tiene el mayor potencial que he visto en un proyecto.
Si codesmith genera código basado en sus tablas, ¿todavía no está estrechamente vinculado a su esquema de datos? Preferiría una solución que desacople mis objetos de mi esquema de base de datos para una mayor flexibilidad en la arquitectura
Es por uno de sus comentarios: es cierto, CodeSmith lo relaciona estrechamente con sus mesas.
NHibernate, por otro lado, tiene muchas características que pueden ayudar con eso: usted tiene Componentes para que en el código pueda tener: Persona con una Dirección de propiedad, donde Dirección es una clase separada.
También mapeo de herencia . Por lo tanto, hace un buen trabajo al desacoplar su esquema de su dominio.
¡No es un carro para saltar, es una reacción a un problema real! El mapeo relacional de objetos (ORM) ha existido por mucho tiempo y resuelve un problema real.
Los lenguajes originales orientados a objetos (OO) trataban de simular problemas del mundo real utilizando un lenguaje informático. Se podría argumentar que si realmente está usando un lenguaje OO para construir sistemas, estará simulando el dominio del problema del mundo real usando un Diseño Dirigido por Dominio (DDD). Esto lógicamente lo lleva a un modelo de separación de preocupaciones para mantener su DDD limpio y despejado de todo el desorden de la persistencia de los datos y los controles de la aplicación.
Cuando construyes sistemas siguiendo un patrón DDD y usas una base de datos relacional para persistencia, entonces realmente necesitas un buen ORM o vas a pasar demasiado tiempo construyendo y manteniendo el crud de la base de datos (juego de palabras intencionado).
ORM es un problema antiguo y fue resuelto hace años por productos como Object Lens y Top Link. Object Lens era un ORM Smalltalk construido por ParkPlace en los años 90. Top Link fue creado por Object People para Smalltalk, luego se convirtió para Java y actualmente lo utiliza Oracle. Top Link también ha existido desde los años 90. Los defensores de DDD ahora están comenzando a articular claramente el caso para DDD y ganar participación mental. Por lo tanto, ORM, por necesidad, se está generalizando y Microsoft simplemente está reaccionando como de costumbre.
Creo que lo que quise decir fue, ¿cuál es la innovación que ofrecen los ORM sobre la construcción de su DAL usando ADO.NET tradicional, SQL y asignándolos a los objetos en el código?
Estos son los tres aspectos principales de mi DAL y estoy comparando con los ORM para ver los beneficios:
Aún debe tener una consulta en ORM = SQL (SQL es mucho más poderoso)
El código de asignación se mueve a la configuración pero aún no se elimina, simplemente cambia de un paradigma a otro
Los objetos deben definirse y administrarse estrechamente relacionados con su esquema de datos a diferencia del enfoque tradicional, que puedo mantenerlos desacoplados.
¿Me estoy perdiendo de algo?
En realidad estoy trabajando en escribir una herramienta ORM en .NET como un proyecto paralelo para mantenerme entretenido.
SQL está muerto para mí. Odio escribirlo, especialmente tenerlo en mi código en cualquier lugar. Escribir manualmente seleccionar / insertar / actualizar / eliminar consultas para cada objeto es una pérdida de tiempo IMO. Y ni siquiera me permite comenzar a manejar NULLs ("donde col_1 =?" Frente a "donde col_1 es nulo") al generar dinámicamente consultas. Las herramientas ORM pueden manejar eso por mí.
Además, tener 1 lugar en el que se genere dinámicamente el SQL podría ser una tarea larga para eliminar los ataques de inyección SQL.
Por otro lado, he usado Hibernate, y lo odio. En un proyecto de palabras reales, nos topamos con limitaciones, bits no implementados y errores cada pocas semanas.
Mantener el lado de la DB de lógica de consulta (generalmente como una vista o procedimiento almacenado) también tiene la ventaja de estar disponible para que los DBA puedan sintonizar. Esa fue una batalla constante en mi último trabajo, usando Hibernate. DBA: "danos todas las consultas posibles para que podamos sintonizar" Devs: "No sé porque Hibernate los generará sobre la marcha. Aunque puedo darte un poco de HQL y un mapeo XML". DBA: "¡No me hagas golpearte en la cara!"
Espero con ansias el día en que mi equipo comience a buscar soluciones ORM. Hasta ese día, somos una tienda pura de DataSet / Stored Procedure y déjenme decirles que no todas las galletas y salsa son "puras".
En primer lugar, el nuevo Linq to SQL se está acercando al de los procesadores y lectores de datos almacenados. Utilizamos conjuntos de datos en todas partes, por lo que el rendimiento mejoraría. Hasta ahora todo bien para ORM.
En segundo lugar, los procesos almacenados tienen el beneficio adicional de ser liberados por separado del código, pero también van en detrimento de ser liberados por separado del código. Imagine por un segundo que tiene una base de datos con más de 5 sistemas conectados y más de 10 personas trabajando en ella. Ahora piense en administrar todos los cambios y dependencias de procedimientos almacenados, especialmente cuando existe una base de código común. Es una pesadilla ...
En tercer lugar, es difícil depurar los procesos almacenados. A menudo resultan en un comportamiento erróneo por varias razones. Esto no quiere decir que no podría ser el resultado del sql dinámico generado por el ORM, pero un problema menos es un problema menor. No hay problemas de permisos (aunque se resuelven en su mayoría en SQL 2005), no hay más desarrollo de pasos múltiples. Escribir la consulta, probar la consulta, implementar la consulta, vincularla al código, probar el código e implementar el código. La consulta es parte del código y veo esto como algo bueno.
En cuarto lugar, aún puede usar procedimientos almacenados. ¿Ejecutar algunos informes que llevan mucho tiempo? Los procesos almacenados son una mejor solución. ¿Por qué? Los planes de ejecución de consultas pueden ser optimizados por el motor de la base de datos. No voy a pretender entender todo el funcionamiento de la base de datos, pero sí sé que existen algunas limitaciones para optimizar el sql dinámico actualmente y que es una compensación que hacemos cuando trabajamos con un ORM. Sin embargo, los procesos almacenados no se descartan al usar una solución ORM.
Realmente, la razón más importante por la que veo que las personas evitan un ORM es que simplemente no tienen experiencia con uno. Habrá una curva de aprendizaje obvia y una etapa de ignorancia. Sin embargo, si va a mejorar el rendimiento del desarrollo y dificultará (o en mi caso mejorará) el rendimiento. Es un intercambio que vale la pena hacer.
He escrito capas de acceso a datos, componentes de persistencia e incluso mis propios ORM en cientos de aplicaciones a lo largo de los años (uno de mis "pasatiempos"); Incluso he implementado mi propio administrador de transacciones comerciales (discutido en otro lugar en SO).
Las herramientas ORM han existido durante mucho tiempo en otras plataformas, como Java, Python, etc. Parece que hay una nueva moda ahora que los equipos centrados en Microsoft las han descubierto. En general, creo que eso es algo bueno, un paso necesario en el camino para explorar y comprender los conceptos de arquitectura y diseño que parece haberse introducido junto con la llegada de .NET.
En pocas palabras: siempre preferiría tener mi propio acceso a los datos en lugar de luchar contra alguna herramienta que esté tratando de "ayudarme". Nunca es aceptable renunciar a mi control sobre mi destino, y el acceso a los datos es una parte fundamental del destino de mi aplicación. Algunos principios simples hacen que el acceso a los datos sea muy manejable.
Use los conceptos básicos de modularidad, abstracción y encapsulación, de modo que envuelva la API de acceso a los datos básicos de su plataforma (por ejemplo, ADO.NET) con su propia capa que eleve el nivel de abstracción más cerca de su espacio problemático. NO codifique todos sus datos de acceso DIRECTAMENTE contra esa API (también se discute en otro lugar en SO).
Aplicar severamente el principio DRY (No repetir) = refactorizar las luces del día de su código de acceso a datos. Use la generación de código cuando sea apropiado como medio de refactorización, pero trate de eliminar la necesidad de generar código cada vez que pueda. En general, la generación de código revela que falta algo en su entorno: deficiencia de lenguaje, diseñada en la limitación de la herramienta, etc.
Mientras tanto, aprenda a usar bien la API disponible, particularmente en lo que respecta al rendimiento y la solidez, y luego incorpore esas lecciones en su propia capa de acceso a datos abstraídos. Por ejemplo, aprenda a hacer un uso adecuado de los parámetros en su SQL en lugar de incorporar valores literales en cadenas de SQL.
Finalmente, tenga en cuenta que cualquier aplicación / sistema que tenga éxito crecerá y encontrará problemas de rendimiento. La solución de problemas de rendimiento se basa más en diseñarlos que en simplemente "ajustar" algo en la implementación. Ese trabajo de diseño afectará la base de datos y la aplicación, que debe cambiar en sincronía. Por lo tanto, intente realizar dichos cambios de forma sencilla (ágil) en lugar de intentar evitar el cambio constante de la aplicación. En parte, eso eventualmente significa poder implementar cambios sin tiempo de inactividad. No es difícil de hacer, si no "diseñas" fuera de él.
No. No todos lo son.
Aquí está el elefante número uno en la sala con la mayoría de las herramientas ORM (especialmente LINQ to SQL:
Se le garantiza que CUALQUIER cambio relacionado con los datos requerirá una redistribución completa de su aplicación.
Por ejemplo, mi trabajo diario actualmente puede corregir la mayoría de los problemas de consulta al modificar un procedimiento almacenado existente y volver a implementar solo esa pieza. Con Linq, et al, sus consultas de datos se trasladan a su código real. ¿Adivina qué significa eso?
ORM es una buena opción para las personas que se llevan bien con el software que les escribe software; pero si eres obsesivo con el control de lo que está sucediendo y por qué, ORM puede no ser óptimo, especialmente con la optimización de la base de datos. Cualquier capa de abstracción tiene costos y beneficios; ORM tiene ambos, pero el saldo aún no es correcto en mi humilde opinión. Y ORM, en su forma actual, irónicamente agrega una capa de abstracción que aún junta las clases y los esquemas de bases de datos no localizados.
Mi experiencia es que puede ayudarlo a obtener una versión de prueba de concepto juntos rápidamente, pero puede introducir requisitos de refactorización con los que quizás no esté familiarizado (al menos todavía).
Agregue a eso, que la herramienta está evolucionando, y las mejores prácticas y patrones no están bien establecidos, ni un consenso del tipo que permite a otros programadores (o futuros programadores) sentirse cómodos con su código. Así que espero ver requisitos de refactorización más altos de lo normal por un tiempo.
Me reservaré el juicio (con optimismo) sobre dónde se resolverá en términos de ser mainstream. No apostaría un proyecto actual en este punto. Mis patrones para lidiar con el desajuste de impedancia son satisfactorios para mis propósitos.
Soy un gran defensor de ORM. La generación de código con ORM le ahorra a mi tienda un 20-30% en la mayoría de nuestros proyectos.
Y tenemos desarrollo de contrato, así que esto es una gran victoria.
Chris Lively hizo un comentario interesante acerca de tener que volver a implementar cada vez que se toca una consulta. Esto puede ser un problema para algunas personas, pero no nos afecta en absoluto. Tenemos reglas contra hacer cambios en la base de datos de producción directamente.
Además, aún puede confiar en los sprocs tradicionales e incluso en las vistas cuando corresponda ... No somos dogmáticos al 100% ORM, eso es seguro.
Soy un gran tipo de ORM, saco la lógica de la base de datos, uso la base de datos solo para la velocidad.
Me encanta la velocidad con la que puedes desarrollar una aplicación. La mayor ventaja, dependiendo del ORM, es que puede cambiar el back-end sin tener que traducir su lógica comercial.
Cambié a LINQ y nunca miré hacia atrás. DBLinq es increíble para hacer otra base de datos que MSSQL. Lo he usado con MY SQL y es GENIAL.
También soy un gran admirador, usando EF y Linq-to-SQL. Mis razones son:
Como LINQ está compilado y es seguro, no se obtienen los problemas de los errores tipográficos en SQL "basado en cadenas". No sé cuántas horas he pasado de mi vida rastreando un error en un SP u otro SQL donde un "tic" u otra palabra clave estaba en el lugar equivocado.
El anterior y otros factores hacen que el desarrollo sea más rápido.
Aunque ciertamente hay una sobrecarga en comparación con los métodos "más cercanos al metal" para consultar las bases de datos, ninguno de nosotros estaría usando .NET en absoluto, o incluso C ++ si el rendimiento era nuestra preocupación # 1. Para la mayoría de las aplicaciones, he podido obtener un excelente rendimiento de Linq-To-SQL, incluso sin utilizar el enfoque de proc almacenado (las consultas compiladas basadas en el cliente es mi enfoque habitual).
Sin embargo, para algunas aplicaciones, aún quieres hacer las cosas a la vieja usanza.
Tienes que luchar con el sistema ORM una vez que quieras hacer algo más que simplemente seleccionar, actualizar o eliminar. Y tu rendimiento va al baño una vez que comienzas a hacer cosas reales.
Entonces no
Todavía utilizamos un DAL cut''n''paste repetitivo y enrollado a mano donde trabajo. Es extremadamente doloroso, complejo y propenso a errores, pero es algo que todos los desarrolladores pueden entender. Aunque nos funciona en este momento, no lo recomiendo, ya que comienza a descomponerse rápidamente en proyectos grandes. Si alguien no quiere ir al completo ORM, al menos recomendaría algún tipo de generación de DAL.
todavía no, aún escéptico; como la mayoría de los productos de Microsoft, espero el SP2 o un año y medio antes de confiar en ellos en un entorno de producción
y tenga en cuenta que prácticamente todo lo nuevo que introduce cualquier persona, no solo Microsoft, es aclamado como "liviano, rápido y fácil", tómelo con un tajo. ¡No publicitan los problemas / problemas tan fuerte como los beneficios / características! Es por eso que esperamos que los primeros usuarios lo descubran.
Esto no es menospreciar ORM o LINQ o algo por el estilo; Me reservo el juicio hasta
- Tengo tiempo para evaluarlos,
- surge alguna necesidad que solo ellos pueden satisfacer,
- la tecnología parece ser lo suficientemente estable como para arriesgarse en uno de los entornos de producción de mis clientes, y / o
- un cliente lo solicita
Tenga en cuenta: he hecho ORM antes, de forma manual, y funcionó bien, así que tengo grandes esperanzas para los sistemas ORM más nuevos.
No me gusta la generación de código utilizada en la mayoría de los ORM. De hecho, la generación de código en general me parece una herramienta débil que generalmente es indicativa de usar el lenguaje equivocado en primer lugar.
En particular con la reflexión de .Net, no veo ninguna necesidad de gen de código para fines de ORM.
Aquí hay una opinión fuerte .
No, dejé ORMs y cambié a smalltalk y a OODB: Gemstone. Mejor código, menos código, desarrollo más rápido.