El Enterprise Objects Framework , o más comúnmente simplemente EOF , fue introducido por NeXT en 1994 como un producto pionero de mapeo relacional de objetos para sus plataformas de desarrollo NeXTSTEP y OpenStep . EOF abstrae el proceso de interacción con una base de datos relacional mediante la asignación de filas de la base de datos a objetos Java o Objective-C . Esto alivia en gran medida a los desarrolladores de escribir código SQL de bajo nivel .
EOF disfrutó de cierto éxito en un nicho a mediados de la década de 1990 entre las instituciones financieras que se sintieron atraídas por las ventajas del rápido desarrollo de aplicaciones de la plataforma orientada a objetos de NeXT. Desde la fusión de Apple Inc con NeXT en 1996, EOF se ha convertido en una parte totalmente integrada de WebObjects , un servidor de aplicaciones también originalmente de NeXT. Muchos de los conceptos centrales de EOF resurgieron como parte de Core Data , que abstrae aún más los formatos de datos subyacentes para permitir que se basen en almacenes que no son SQL.
Historia
A principios de la década de 1990, NeXT Computer reconoció que conectarse a bases de datos era esencial para la mayoría de las empresas y, sin embargo, también potencialmente complejo. Cada fuente de datos tiene un lenguaje de acceso a datos (o API ) diferente, lo que aumenta los costos para aprender y usar el producto de cada proveedor. Los ingenieros de NeXT querían aplicar las ventajas de la programación orientada a objetos , haciendo que los objetos "hablaran" con las bases de datos relacionales. Como las dos tecnologías son muy diferentes, la solución fue crear una capa de abstracción, aislando a los desarrolladores de escribir el código de procedimiento de bajo nivel ( SQL ) específico para cada fuente de datos.
El primer intento se produjo en 1992 con el lanzamiento de Database Kit (DBKit), que envolvió un marco orientado a objetos alrededor de cualquier base de datos. Desafortunadamente, NEXTSTEP en ese momento no era lo suficientemente potente y DBKit tenía serios defectos de diseño.
El segundo intento de NeXT se produjo en 1994 con la versión 1 de Enterprise Objects Framework (EOF), una reescritura completa que era mucho más modular y compatible con OpenStep . EOF 1.0 fue el primer producto lanzado por NeXT usando el Foundation Kit e introdujo objetos liberados automáticamente a la comunidad de desarrolladores. El equipo de desarrollo en ese momento era solo de cuatro personas: Jack Greenfield, Rich Williamson, Linus Upson y Dan Willhite. EOF 2.0, lanzado a finales de 1995, perfeccionó aún más la arquitectura, introduciendo el contexto de edición. En ese momento, el equipo de desarrollo estaba formado por Dan Willhite, Craig Federighi , Eric Noyau y Charly Kleissner.
EOF alcanzó un nivel modesto de popularidad en la comunidad de programación financiera a mediados de la década de 1990, pero se haría realidad con el surgimiento de la World Wide Web y el concepto de aplicaciones web . Estaba claro que EOF podría ayudar a las empresas a conectar sus bases de datos heredadas a la Web sin tener que volver a escribir esos datos. Con la incorporación de marcos para la gestión de estados, el equilibrio de carga y la generación dinámica de HTML, NeXT pudo lanzar el primer servidor de aplicaciones web orientado a objetos, WebObjects , en 1996, con EOF en su núcleo.
En 2000, Apple Inc. (que se había fusionado con el siguiente) eliminó oficialmente EOF como un producto independiente, lo que significa que los desarrolladores no podrían utilizarlo para crear aplicaciones de escritorio para el próximo Mac OS X . Sin embargo, seguirá siendo una parte integral de una nueva versión importante de WebObjects. WebObjects 5, lanzado en 2001, fue significativo por el hecho de que sus marcos habían sido trasladados de su lenguaje de programación nativo Objective-C al lenguaje Java . Los críticos de este cambio argumentan que la mayor parte del poder de EOF fue un efecto secundario de sus raíces Objective-C, y que EOF perdió la belleza o simplicidad que alguna vez tuvo. Las herramientas de terceros, como EOGenerator , ayudan a subsanar las deficiencias introducidas por Java (principalmente por la pérdida de categorías ).
El código base de Objective-C se reintrodujo con algunas modificaciones para los desarrolladores de aplicaciones de escritorio como Core Data , parte de la API Cocoa de Apple , con el lanzamiento de Mac OS X Tiger en abril de 2005.
Cómo funciona EOF
Enterprise Objects proporciona herramientas y marcos para el mapeo relacional de objetos. La tecnología se especializa en proporcionar mecanismos para recuperar datos de varias fuentes de datos, como bases de datos relacionales a través de directorios JDBC y JNDI, y mecanismos para enviar datos a esas fuentes de datos. Estos mecanismos están diseñados en un enfoque abstracto en capas que permite a los desarrolladores pensar en la recuperación de datos y el compromiso a un nivel más alto que una fuente de datos específica o un proveedor de fuente de datos.
El elemento central de esta asignación es un archivo de modelo (un "EOModel") que se crea con una herramienta visual, ya sea EOModeler o el complemento EOModeler para Xcode . El mapeo funciona de la siguiente manera:
- Las tablas de la base de datos se asignan a las clases.
- Las columnas de la base de datos se asignan a los atributos de la clase.
- Las filas de la base de datos se asignan a objetos (o instancias de clase).
Puede crear modelos de datos basados en fuentes de datos existentes o puede crear modelos de datos desde cero, que luego utiliza para crear estructuras de datos (tablas, columnas, combinaciones) en una fuente de datos. El resultado es que los registros de la base de datos se pueden transponer a objetos Java.
La ventaja de utilizar modelos de datos es que las aplicaciones están aisladas de las idiosincrasias de las fuentes de datos a las que acceden. Esta separación de la lógica empresarial de una aplicación de la lógica de la base de datos permite a los desarrolladores cambiar la base de datos a la que accede una aplicación sin necesidad de cambiar la aplicación.
EOF proporciona un nivel de transparencia de base de datos que no se ve en otras herramientas y permite que se utilice el mismo modelo para acceder a bases de datos de diferentes proveedores e incluso permite relaciones entre bases de datos de diferentes proveedores sin cambiar el código fuente.
Su poder proviene de exponer las fuentes de datos subyacentes como gráficos administrados de objetos persistentes. En términos simples, esto significa que organiza la capa del modelo de la aplicación en un conjunto de objetos de datos en memoria definidos. Luego, rastrea los cambios en estos objetos y puede revertir esos cambios a pedido, como cuando un usuario ejecuta un comando de deshacer. Luego, cuando llega el momento de guardar los cambios en los datos de la aplicación, archiva los objetos en las fuentes de datos subyacentes.
Usando herencia
Al diseñar Enterprise Objects, los desarrolladores pueden aprovechar la característica orientada a objetos conocida como herencia . Un objeto Cliente y un objeto Empleado, por ejemplo, pueden heredar determinadas características de un objeto Persona más genérico, como el nombre, la dirección y el número de teléfono. Si bien este tipo de pensamiento es inherente al diseño orientado a objetos, las bases de datos relacionales no tienen soporte explícito para la herencia. Sin embargo, con Enterprise Objects, puede crear modelos de datos que reflejen jerarquías de objetos. Es decir, puede diseñar tablas de base de datos para admitir la herencia diseñando también objetos empresariales que se asignan a varias tablas o vistas particulares de una tabla de base de datos.
¿Qué es un objeto empresarial (EO)?
Un objeto empresarial es análogo a lo que a menudo se conoce en la programación orientada a objetos como un objeto empresarial : una clase que modela un objeto físico o conceptual en el dominio empresarial (por ejemplo, un cliente, un pedido, un artículo, etc.). Lo que hace que un EO sea diferente de otros objetos es que sus datos de instancia se asignan a un almacén de datos. Normalmente, un objeto empresarial contiene pares clave-valor que representan una fila en una base de datos relacional. La clave es básicamente el nombre de la columna y el valor es lo que estaba en esa fila en la base de datos. Por lo tanto, se puede decir que las propiedades de un EO persisten más allá de la vida útil de cualquier aplicación en ejecución en particular.
Más precisamente, un objeto empresarial es una instancia de una clase que implementa la interfaz com.webobjects.eocontrol.EOEnterpriseObject.
Un objeto empresarial tiene un modelo correspondiente (llamado EOModel) que define el mapeo entre el modelo de objeto de la clase y el esquema de la base de datos. Sin embargo, un objeto empresarial no conoce explícitamente su modelo. Este nivel de abstracción significa que los proveedores de bases de datos se pueden cambiar sin afectar el código del desarrollador. Esto le da a Enterprise Objects un alto grado de reutilización.
EOF y datos básicos
A pesar de sus orígenes comunes, las dos tecnologías divergieron, y cada tecnología retuvo un subconjunto de las características del código base original de Objective-C, al tiempo que agregó algunas características nuevas.
Funciones compatibles solo con EOF
EOF admite SQL personalizado; contextos de edición compartidos; contextos de edición anidados; y recuperación previa y fallas por lotes de relaciones, todas las características de la implementación original de Objective-C no son compatibles con Core Data. Core Data tampoco proporciona el equivalente de un EOModelGroup; la clase NSManagedObjectModel proporciona métodos para fusionar modelos de modelos existentes y para recuperar modelos fusionados de paquetes.
Funciones compatibles solo con datos básicos
Core Data admite propiedades obtenidas; múltiples configuraciones dentro de un modelo de objeto gestionado; tiendas locales; y agregación de tiendas (los datos de una entidad determinada pueden estar distribuidos en varias tiendas); personalización y localización de nombres de propiedad y advertencias de validación; y el uso de predicados para la validación de propiedades. Estas características de la implementación de Objective-C original no son compatibles con la implementación de Java.