Como desarrollador web en busca pasar de mano el código PHP sitios marco basado en los sitios, he visto un montón de discusión acerca de las ventajas de un ORM sobre la otra. Parece ser útil para proyectos de un cierto (?) tamaño, y aún más importante para las aplicaciones de nivel empresarial.

¿Qué me dan como un desarrollador? ¿Cómo va mi código diferir de las instrucciones SELECT individuales que uso ahora? Cómo va a ayudar con la DB de acceso y seguridad? ¿Cómo averiguar sobre el esquema DB y las credenciales de usuario?

Edición: @duffymo señaló lo que debería haber sido obvio para mí: ORM sólo es útil para la programación orientada a objetos. Mi código no es OO, por lo que no he corrido en los problemas que ORM resuelve.

  • Le sugiero que experimento con el ORM de la manera que se supone que debe hacer-mira en Ruby on Rails y Registro Activo–construir un demo y cambiar un par de cosas. Es bastante ingenioso. Dicho esto, las implementaciones que he visto se basan en gran medida en los setters y getters y la mayoría de los programadores, siendo naturalmente perezoso, dejar los setters y getters externo que hacer para no tan buena OO.
  • He visto hecho en Grails, y he usado un estado de Hibernación. Yo todavía de pie por mi respuesta.
InformationsquelleAutor flamingLogos | 2008-12-29

13 Comentarios

  1. 86

    Yo diría que si usted no está lidiando con los objetos que hay poco punto en el uso de un ORM.

    Si su relacional de tablas/columnas mapa 1:1 con los objetos y atributos, no hay mucho punto en el uso de un ORM.

    Si los objetos no tienen ninguna 1:1, 1:m o m:n relaciones con otros objetos, no hay mucho punto en el uso de un ORM.

    Si tienes complejo, de la mano afinado de SQL, no hay mucho punto en el uso de un ORM.

    Si usted ha decidido que su base de datos tendrá los procedimientos almacenados como su interfaz, no hay mucho punto en el uso de un ORM.

    Si usted tiene un legado complejo esquema que no puede ser refactorizado, no hay mucho punto en el uso de un ORM.

    Así que aquí es lo contrario:

    Si usted tiene un sólido modelo de objetos, con las relaciones entre los objetos que son de 1:1, 1:m, y m:n, no tiene procedimientos almacenados, y como el SQL dinámico que un ORM solución le dará, por todos los medios el uso de un ORM.

    Decisiones como estas son siempre una elección. Elegir, implementar, medir, evaluar.

    • Mi código no es OO, por lo que no he corrido contra el mapeo objeto/relacional tema. Por eso es que estoy teniendo problemas para visualizar cómo ORM gustaría mejorar mi código. Gracias!
    • 1:1 de la tabla de asignaciones de caer bajo el modelo de Registro Active que es una forma muy popular para el uso de Orm. El mapeo de objetos a varias tablas es sólo una de las varias características de un ORM. La respuesta que me dieron se enumeran algunas de las características que usted va a obtener mediante el uso de un ORM incluso con 1:1 de la tabla de asignaciones.
    • De acuerdo, pero yo no llamaría Registro Activo ORM la mejor hora. Creo que engaña a las personas que no han pensado acerca de un verdadero modelo de objetos en el pensamiento de que está haciendo lo correcto.
    • Así que puede ser infered que hay no point en el uso de ORM tecnologías ?
    • Hola Raquel, consulte actualización de arriba.
    • ¿De verdad quiere decir que ORM no debe usar para ese tipo de sistema que utiliza storedprocedures ya ?
    • depende de lo que los procedimientos almacenados están haciendo, pero sí, por supuesto, sabía de lo que hablaba.

  2. 38

    Orm están siendo promocionado para ser la solución a los problemas de Acceso a los Datos. Personalmente, después de haber utilizado en un Proyecto de Empresa, están lejos de ser la solución para el Desarrollo de Aplicaciones Empresariales. Tal vez el trabajo en pequeños proyectos. Aquí están los problemas que hemos experimentado con ellos específicamente nHibernate:

    1. De configuración: ORM tecnologías requieren los archivos de configuración para asignar esquemas de tabla en las estructuras de los objetos. En los grandes sistemas de la empresa a la configuración crece muy rápidamente y se convierte en extremadamente difícil crear y administrar. El mantenimiento de la configuración también se vuelve tedioso y tanto el como los requisitos de negocio y modelos en constante cambio y evolucionar en un entorno ágil.

    2. Consultas personalizadas: La capacidad de asignar consultas personalizadas que no encajan en cualquier objeto definido no es compatible o no recomendados por el marco de los proveedores. Los desarrolladores están obligados a encontrar soluciones por escrito adhoc objetos y consultas, o escribir código personalizado para obtener los datos que necesitan. Puede que tenga que utilizar Procedimientos Almacenados en una base regular para algo más complejo que un simple Select.

    3. Proprietery encuadernación: Estos marcos requieren el uso de la propiedad de las bibliotecas y de la propiedad objeto de la consulta idiomas que no están estandarizadas en la ciencia de la computación de la industria. Estos de propiedad de las bibliotecas y los lenguajes de consulta de obligar a la aplicación específica a la aplicación del proveedor con poca o ninguna flexibilidad para cambiar si es necesario y no de la interoperabilidad para colaborar el uno con el otro.

    4. Objeto de Lenguajes de Consulta: Nueva consulta lenguajes llamados Lenguajes de Consulta de Objeto se proporcionan para realizar consultas sobre el modelo de objetos. Que generan de forma automática consultas SQL contra la databse y el usuario se abstrae del proceso. A Objeto de desarrolladores Orientados esto puede parecer una ventaja ya que ellos sienten que el problema de escritura de SQL está resuelto. El problema en la práctica es que estos lenguajes de consulta no puede apoyar algunas de las de nivel intermedio a avanzado de SQL construcciones requerido por la mayoría de las aplicaciones del mundo real. También evitar que los desarrolladores de ajustar las consultas SQL si es necesario.

    5. Rendimiento: El ORM capas de utilizar la reflexión y la introspección para crear y rellenar los objetos con los datos de la base de datos. Estas son las operaciones costosas en términos de procesamiento y agregar a la degradación del rendimiento de las operaciones de asignación. El Objeto de las Consultas que se traducen a producir unoptimized consultas sin la opción de sintonización de ellos causando importantes pérdidas en el rendimiento y la sobrecarga de la base de datos de los sistemas de gestión. La optimización del rendimiento de SQL es casi imposible, ya que los marcos de proporcionar a poco flexiblity sobre el control de la SQL que obtiene autogenerado.

    6. Estrecho acoplamiento: Este enfoque crea una estrecha dependencia entre el modelo de objetos y esquemas de base de datos. Los desarrolladores no quieren un uno-a-uno correlación entre los campos de base de datos y los campos de la clase. Cambiar el esquema de base de datos ha de ondulación afecta en el modelo de objetos y la configuración de la asignación y viceversa.

    7. Caché: Este enfoque también requiere el uso de objetos de caché y contextos que son necesarios para maintian y rastrear el estado del objeto y reducir la base de datos de viajes de ida y vuelta para los datos almacenados en caché. Estos cachés si no se mantiene y synchrnonized en un multi-tiered aplicación puede tener consecuencias significativas en términos de los datos de precisión y la simultaneidad. A menudo, el tercer partido de la caché o externo cachés tiene que estar conectado para resolver este problema, añadiendo extensa carga para la capa de acceso a datos.

    Para obtener más información acerca de nuestro análisis se puede leer:
    http://www.orasissoftware.com/driver.aspx?topic=whitepaper

    • En mi opinión, este «análisis» plantea más preguntas que en realidad no responde nada. La mayoría de las afirmaciones son o de plano mal, al menos con respecto a Hibernar (2, 4, 5, 7), demasiado general (1, 6), o engañosa, (3, 4, 6).
    • Hibernate crea más problemas de los que resuelve. «Vamos a resolver el SQL y relacional-objeto problema!» GENIAL!!! Y para ello vamos a introducir un millón de otras complejidades. De ninguna manera. ORM como Hibernate es un enorme DISIPADOR, a menos que usted nunca oyó hablar acerca de las bases de datos, SQL, JDBC, etc. No digo que debe manejar el aburrido JDBC de la caldera de la placa, pero hay muchas soluciones para abordar esta mucho más simple problema: iBatis, jOOQ y MentaBean. Si te gusta estar tan cerca como sea posible a SQL usted debe comprobar MentaBean: mentabean.soliveirajr.com
    • Si usted está lo que bien junto a SQL es probable que su dominio objeto de diseño es pobre.
  3. 33

    A un nivel muy alto: Orm ayudar a reducir el Objeto-Relacional desajuste de impedancia. Que permiten almacenar y recuperar completo de los objetos de una base de datos relacional sin hacer un montón de análisis/serialización de sí mismo.

    ¿Qué me dan como un desarrollador?

    Para empezar le ayuda a mantenerse SECO. Ya sea que usted esquema o modelo de clases están autorizadas y el otro es generado automáticamente, lo que reduce el número de errores y la cantidad de la caldera de la placa de código.

    Ayuda con el cálculo de referencias. Orm manejan generalmente de cálculo de los valores de cada una de las columnas en los tipos adecuados de modo que usted no tiene que analizar/serializar a ti mismo. Además, permite recuperar completamente formado objeto de la base de datos en lugar de simplemente fila de objetos de los que dispone para envolver a su auto.

    ¿Cómo va mi código diferir de las instrucciones SELECT individuales que uso ahora?

    Desde las consultas devuelven objetos en vez de simplemente filas, usted será capaz de acceder a los objetos relacionados con el uso de atributo de acceso en lugar de crear una nueva consulta. En general eres capaz de escribir SQL directamente cuando usted lo necesita, pero para la mayoría de las operaciones (CRUD) el ORM va a hacer el código para interactuar con la persistencia de los objetos más simples.

    ¿Cómo va a ayudar con la DB de acceso y seguridad?

    Generalmente hablando, Orm tiene su propia API para la creación de consultas (por ejemplo. atributo de acceso) y por eso, son menos vulnerables a los ataques de inyección SQL; sin embargo, a menudo permiten inyectar su propio SQL en las consultas generadas de modo que usted puede hacer cosas extrañas, si es necesario. Tal SQL inyectado usted es responsable para la desinfección de sí mismo, pero, en caso de permanecer lejos de el uso de tales características, a continuación, el ORM se debe tener el cuidado de desinfectar los datos de usuario de forma automática.

    ¿Cómo averiguar sobre el esquema DB y las credenciales de usuario?

    Muchos Orm vienen con las herramientas de que se inspeccione un esquema y construir un conjunto de clases del modelo que le permiten interactuar con los objetos en la base de datos. [Base de datos] las credenciales de usuario se almacenan generalmente en un archivo de configuración.

  4. 14

    Si usted escribe su capa de acceso a datos a mano, que son esencialmente de la escritura de su propia característica pobres ORM.

    Oren Eini tiene un bonito blog que resume lo esencial de las características que usted puede necesitar en su DAL/ORM y por qué es la escritura de su propia convierte en una mala idea después de tiempo:
    http://ayende.com/Blog/archive/2006/05/12/25ReasonsNotToWriteYourOwnObjectRelationalMapper.aspx

    EDIT: La OP ha comentado en otras respuestas que su base de código no es muy orientado a objetos. Tratar con objeto de asignación es sólo una faceta de Orm. El Active Record patrón es un buen ejemplo de cómo Orm todavía son útiles en escenarios donde los objetos de mapa de 1:1 a las tablas.

    • …justo cuando estaba a punto de presentar el mismo enlace
  5. 9

    Yo no puedo hablar por otros ORM, justo Hibernate (de Java).

    Hibernate me da el siguiente:

    • Actualiza automáticamente el esquema de tablas sobre la producción del sistema en tiempo de ejecución. A veces, usted todavía tiene que actualizar algunas cosas manualmente.
    • Crea automáticamente las claves externas que le impide escribir el código de malo que es la creación de huérfanos de datos.
    • Implementa la agrupación de conexiones. Varios de agrupación de los proveedores están disponibles.
    • Cachés de datos para un acceso más rápido. Varios proveedores de almacenamiento en caché están disponibles. Esto también permite que usted se agrupan muchos servidores para ayudarle a escala.
    • Hace que la base de datos de acceso más transparente, de modo que usted puede fácilmente puerto de su aplicación a otra base de datos.
    • Hacer consultas más fácil de escribir. La siguiente consulta, que normalmente requieren que usted escriba ‘unirse’ tres veces puede ser escrita así:
      • «de Factura i donde i.cliente.dirección.ciudad = ?», esto recupera todas las facturas con una ciudad específica
      • una lista de Factura devuelve los objetos. Me puede llamar factura.getCustomer().getCompanyName(); si los datos ya no está en la caché de la base de datos se consulta de forma automática en segundo plano

    Puede aplicar ingeniería inversa a una base de datos para crear el esquema de hibernación (no he probado a mí mismo) o se puede crear el esquema de cero.

    Por supuesto, hay una curva de aprendizaje como con cualquier nueva tecnología, pero creo que merece la pena.

    Cuando es necesario que usted todavía puede bajar a la parte inferior nivel de SQL para escribir una optimización de consultas.

  6. 8

    Beneficios De La Parte Superior:

    1. Abstracción De Base De Datos
    2. API-diseño centrado en la mentalidad
    3. De alto Nivel == Menos de la que preocuparse en el nivel fundamental (su sido pensado para usted)

    Tengo que decir, trabajando con un ORM es realmente la evolución de bases de datos de las aplicaciones. Se preocupan menos acerca de el estándar SQL escribes siempre, y más en cómo las interfaces pueden trabajar juntos para hacer una muy sencilla del sistema.

    Me encanta no tener que preocuparse de INNER JOIN y SELECT COUNT(*). Acabo de trabajo en mi alto nivel de abstracción, y me he tomado el cuidado de abstracción de base de datos al mismo tiempo.

    Habiendo dicho esto, yo nunca realmente han de ejecutar en un tema donde yo necesarios para ejecutar el mismo código en más de un sistema de base de datos en un tiempo realista. Sin embargo, eso no quiere decir que en caso de no existir, se trata de un problema muy real para algunos desarrolladores.

  7. 6

    La mayoría de las bases de datos utilizadas son las bases de datos relacionales que no se traduce a objetos. Qué es un Asignador de Objeto-Relacional que hace es tomar los datos, crear una cubierta que lo rodea con las funciones de utilidad para actualizar, eliminar, insertar, y otras operaciones que se pueden realizar. Así que en lugar de pensar en él como una matriz de filas, ahora tienes una lista de objetos que se pueden manipular como cualquier otro y simplemente llame a obj.Guardar() cuando haya terminado.

    Te sugiero que eche un vistazo a algunos de los ORM que estén en uso, uno de mis favoritos es el ORM utilizado en python marco, django. La idea es que escribas una definición de cómo parece que sus datos en la base de datos y el ORM de atención de validación, cheques y cualquier mecánica que deben ejecutarse antes de que se inserten los datos.

  8. 5

    Personalmente no he tenido una gran experiencia con el uso de ORM tecnología hasta la fecha. Actualmente estoy trabajando para una empresa que utiliza nHibernate y yo realmente no puedo seguir con él. Dame un procedimiento almacenado y DAL cualquier día! Más código seguro … pero también más control y el código más fácil de depurar – a partir de mi experiencia en el uso de una versión temprana de nHibernate tiene que ser añadido.

  9. 4

    ¿Qué me dan como un desarrollador?

    Le ahorra tiempo, ya que usted no tiene el código de la db de acceso de la parte.

    ¿Cómo va mi código diferir de las instrucciones SELECT individuales que uso ahora?

    Usted utilizar los atributos o archivos xml para definir la asignación de clase para las tablas de base de datos.

    ¿Cómo va a ayudar con la DB de acceso y seguridad?

    La mayoría de los marcos tratar de adherirse a db mejores prácticas aplicables, tales como SQL parametrizadas y tal. Debido a que la implementación de detalle es codificada en el marco, usted no tiene que preocuparse acerca de esto. Por esta razón, sin embargo, también es importante para entender el marco que se está utilizando, y ser consciente de los defectos de diseño o errores que se pueden abrir agujeros inesperados.

    ¿Cómo averiguar sobre el esquema DB y las credenciales de usuario?

    Que proporcione la cadena de conexión como siempre. El marco de los proveedores (por ejemplo, SQL, Oracle, MySQL clases específicas) proporcionar la implementación de las consultas de la base de datos de esquema, los procesos de la clase de asignaciones, y hace /se ejecuta la base de datos de código de acceso según sea necesario.

  10. 4

    El uso de un ORM va a quitar las dependencias de su código en un determinado dialecto de SQL. En lugar de interactuar directamente con la base de datos que va a estar interactuando con una capa de abstracción que proporciona un aislamiento entre el código y la base de datos de la aplicación. Además, Orm normalmente proporcionan la protección de la inyección de SQL mediante la construcción de consultas parametrizadas. Concedido usted puede hacer esto por sí mismo, pero es bueno disponer de un marco de garantía.

    Orm trabajo en una de dos maneras: algunas descubrir el esquema de una base de datos existente — el LINQToSQL diseñador hace esto -, otros requieren que usted mapa de su clase en una tabla. En ambos casos, una vez que el esquema ha sido asignado, el ORM puede ser capaz de crear (recrear) su estructura de base de datos para usted. DB permisos probablemente todavía necesitan ser aplicado a mano o a través de SQL personalizada.

    Normalmente, las credenciales suministradas mediante programación a través de la API o mediante un archivo de configuración, o ambas cosas, por defecto viene desde un archivo de configuración, pero que puede reemplazar en el código.

  11. 1

    Aunque estoy de acuerdo con el aceptado respuesta casi por completo, creo que puede ser modificado con ligero alternativas en mente.

    • Si usted tiene complejo de mano, atentos SQL
    • Si los objetos no tienen ninguna 1:1, 1:m o m:n relaciones con otros objetos
    • Si usted tiene un legado complejo esquema que no puede ser refactorizado

    …entonces usted podría beneficiarse de un ligero ORM donde SQL no es
    oculta o se abstrae hasta el punto donde es más fácil escribir su
    una base de datos propia integración.

    Estas son algunas de las muchas razones por las que el equipo de desarrolladores en mi empresa decidió que se necesitaba para hacer más flexible la abstracción a residir en la parte superior de la JDBC.

    Hay muchas alternativas de código abierto alrededor que lograr cosas similares, y jORM es nuestra propuesta de solución.

    Yo recomendaría para evaluar algunos de los más firmes candidatos antes de elegir un ligero ORM. Son ligeramente diferentes en su enfoque abstracto bases de datos, pero puede ser similar a partir de una vista de arriba hacia abajo.

  12. 0

    mi preocupación con ORM marcos es probablemente la cosa que la hace atractiva para muchos desarrolladores.

    nameley que se evita la necesidad de «atención» acerca de lo que está pasando en el nivel de DB. La mayoría de los problemas que vemos durante el día a día de nuestras aplicaciones están relacionadas con problemas de base de datos. Me preocupa ligeramente sobre un mundo que es 100% ORM que la gente no sabe acerca de lo que las consultas están golpeando a la base de datos, o si lo hacen, no están seguros acerca de cómo cambiar u optimizar ellos.

    {Me doy cuenta de que esto puede ser un contraversial respuesta 🙂 }

Dejar respuesta

Please enter your comment!
Please enter your name here