villano personaje mapeo framework ejemplos datos database orm

database - mapeo - orm personaje



¿Por qué deberías usar un ORM? (16)

Si tuviera que motivar a los "profesionales" de por qué usaría un ORM para administración / cliente, ¿cuáles serían las razones?

Intenta mantener un motivo por respuesta para que podamos ver qué se vota como las mejores razones

Compilación y prueba de consultas.

A medida que las herramientas para ORM mejoran, es más fácil determinar la corrección de sus consultas más rápidamente a través de pruebas y errores de tiempo de compilación.

La compilación de sus consultas ayuda a los desarrolladores a encontrar errores más rápidamente. ¿Derecha? Derecha. Esta compilación es posible porque los desarrolladores ahora están escribiendo consultas en código utilizando sus objetos comerciales o modelos en lugar de solo cadenas de SQL o sentencias similares a SQL.

Si utiliza los patrones correctos de acceso a datos en .NET, es fácil probar su lógica de consulta en colecciones de memoria. Esto acelera la ejecución de sus pruebas porque no necesita acceder a la base de datos, configurar datos en la base de datos o incluso girar un contexto de datos completo. [EDITAR] Esto no es tan cierto como pensé que era como unidad las pruebas en la memoria pueden presentar desafíos difíciles de superar. Pero todavía encuentro estas pruebas de integración más fáciles de escribir que en años anteriores. [/ EDITAR]

Esto es definitivamente más relevante hoy que hace unos años cuando se formuló la pregunta, pero tal vez solo sea el caso de Visual Studio y Entity Framework, donde reside mi experiencia. Completa tu propio entorno si es posible.

Creo que hay muchos puntos buenos aquí (portabilidad, facilidad de desarrollo / mantenimiento, enfoque en el modelado de negocios OO, etc.), pero al tratar de convencer a su cliente o gerencia, todo se reduce a la cantidad de dinero que ahorrará al usar un ORM .

Haga algunas estimaciones para las tareas típicas (o incluso proyectos más grandes que puedan estar surgiendo) y usted (¡con suerte!) Obtendrá algunos argumentos para el cambio que son difíciles de ignorar.

Creo que uno de los inconvenientes es que ORM necesitará alguna actualización en su POJO. principalmente relacionado con el esquema, la relación y la consulta. por lo tanto, el escenario en el que no se supone que debe hacer cambios en los objetos del modelo puede deberse a que se comparte entre más que en el proyecto o el cliente y el servidor en b / n. entonces, en tales casos, tendrá que dividirlo en dos niveles, lo que requerirá esfuerzos adicionales.

Soy un desarrollador de Android y, como usted sabe, las aplicaciones móviles generalmente no son de gran tamaño, por lo que este esfuerzo adicional para segregar el modelo puro y el modelo afectado por orm no parece que valga la pena.

Entiendo que la pregunta es genérica. pero las aplicaciones móviles también vienen dentro de un paraguas genérico.

Desarrollo acelerado Por ejemplo, eliminando el código repetitivo como asignar campos de resultados de consulta a los miembros del objeto y viceversa.

Felicidad de desarrollo, IMO. ORM elimina muchas de las cosas básicas que tienes que hacer en SQL. Mantiene simple su base de código: menos archivos de origen para administrar y cambios de esquema no requieren horas de mantenimiento.

Actualmente estoy usando un ORM y ha acelerado mi desarrollo.

Generando código repetitivo para operaciones CRUD básicas. Algunos marcos ORM pueden inspeccionar los metadatos de la base de datos directamente, leer archivos de asignación de metadatos o usar propiedades de clase declarativa.

Hacer que el acceso a los datos sea más abstracto y portátil. Las clases de implementación ORM saben cómo escribir SQL específicos del proveedor, por lo que no es necesario.

La razón más importante para usar un ORM es que pueda tener un modelo de negocio rico orientado a objetos y aún así poder almacenarlo y escribir consultas efectivas rápidamente contra una base de datos relacional. Desde mi punto de vista, no veo ninguna ventaja real que un buen ORM le de cuando se compara con otros DAL generados que no sean los tipos avanzados de consultas que puede escribir.

Un tipo de consulta en la que estoy pensando es una consulta polimórfica. Una consulta ORM simple puede seleccionar todas las formas en su base de datos. Usted recupera una colección de formas. Pero cada instancia es un cuadrado, un círculo o un rectángulo de acuerdo con su discriminador.

Otro tipo de consulta sería aquella que busca con impaciencia un objeto y uno o más objetos relacionados o colecciones en una sola llamada a la base de datos. Por ejemplo, cada objeto de forma se devuelve con su vértice y las colecciones laterales pobladas.

Lamento no estar de acuerdo con tantos otros aquí, pero no creo que la generación de código sea una buena razón para ir con un ORM. Puede escribir o encontrar muchas plantillas DAL buenas para generadores de código que no tienen la sobrecarga conceptual o de rendimiento que tienen los ORM.

O bien, si crees que no necesitas saber cómo escribir buenos SQL para usar un ORM, de nuevo, no estoy de acuerdo. Es posible que, desde la perspectiva de escribir consultas individuales, confiar en un ORM sea más fácil. Pero, con los ORM es demasiado fácil crear rutinas de bajo rendimiento cuando los desarrolladores no entienden cómo funcionan sus consultas con el ORM y el SQL al que traducen.

Tener una capa de datos que funcione contra múltiples bases de datos puede ser un beneficio. Sin embargo, no he tenido que confiar en eso con frecuencia.

Al final, tengo que reiterar que en mi experiencia, si no está utilizando las funciones de consulta más avanzadas de su ORM, existen otras opciones que resuelven los problemas restantes con menos aprendizaje y menos ciclos de CPU.

Oh, sí, algunos desarrolladores encuentran que trabajar con ORM es divertido, por lo que los ORM también son buenos desde la perspectiva de mantener a los desarrolladores felices. =)

La razón por la que lo busco es evitar el código generado de las herramientas DAL de VS2005 (asignación de esquema, TableAdapters).

El DAL / BLL que creé hace más de un año funcionaba bien (para lo que lo había construido) hasta que alguien más comenzó a usarlo para aprovechar algunas de las funciones generadas (que no tenía ni idea de dónde estaban)

Parece que proporcionará una solución mucho más intuitiva y más limpia que la solución DAL / BLL de http://wwww.asp.net

Estaba pensando en crear mi propio generador de código SQL Command C # DAL, pero el ORM parece una solución más elegante

Para minimizar la duplicación de consultas SQL simples.

Para que coincida su modelo de objeto y modelo de persistencia.

Puede moverse fácilmente a un software de base de datos diferente porque está desarrollando una abstracción.

Resuma el SQL el 95% del tiempo, de modo que no todos en el equipo necesiten saber cómo escribir consultas específicas de bases de datos súper eficientes.

Soporte de encapsulamiento OO de las reglas comerciales en su capa de acceso a datos. Puede escribir (y depurar) las reglas comerciales en el idioma de preferencia de su aplicación, en lugar de un disparador torpe y lenguajes de procedimientos almacenados.

convencerlos de cuánto tiempo / dinero ahorrará cuando entren los cambios y no tenga que volver a escribir su SQL ya que la herramienta ORM lo hará por usted