El Enterprise Objects Framework , o 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 asignando filas de la base de datos a objetos Java u Objective-C . Esto libera en gran medida a los desarrolladores de escribir código SQL de bajo nivel . [1]
EOF disfrutó de cierto éxito de 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 ha evolucionado hasta convertirse en una parte totalmente integrada de WebObjects , un servidor de aplicaciones también originario 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 sean SQL.
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 de aprender y utilizar 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 "hablen" con 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 envolvía 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 Enterprise Objects Framework (EOF) versión 1, una reescritura completa que era mucho más modular y compatible con OpenStep . EOF 1.0 fue el primer producto lanzado por NeXT utilizando Foundation Kit e introdujo objetos de publicación automática a la comunidad de desarrolladores. El equipo de desarrollo en ese momento estaba formado por sólo 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 e introdujo 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 destacaría 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 reescribir esos datos. Con la adición de marcos para realizar gestión de estado, equilibrio de carga y generación dinámica de HTML, NeXT pudo lanzar el primer servidor de aplicaciones web orientado a objetos, WebObjects , en 1996, con EOF como núcleo.
En 2000, Apple Inc. (que se había fusionado con NeXT) eliminó oficialmente EOF como 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ía siendo una parte integral de una nueva versión importante de WebObjects. WebObjects 5, lanzado en 2001, fue importante por el hecho de que sus marcos habían sido portados desde 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. Herramientas de terceros, como EOGenerator, ayudan a suplir las deficiencias introducidas por Java (principalmente por la pérdida de categorías ).
El código base Objective-C se reintrodujo con algunas modificaciones para los desarrolladores de aplicaciones de escritorio como Core Data , parte de Cocoa API de Apple , con el lanzamiento de Mac OS X Tiger en abril de 2005.
Enterprise Objects proporciona herramientas y marcos para el mapeo relacional de objetos. La tecnología se especializa en proporcionar mecanismos para recuperar datos de diversas fuentes de datos, como bases de datos relacionales a través de directorios JDBC y JNDI, y mecanismos para devolver datos a esas fuentes de datos. Estos mecanismos están diseñados con un enfoque abstracto en capas que permite a los desarrolladores pensar en la recuperación y el compromiso de datos a un nivel más alto que una fuente de datos específica o un proveedor de fuentes de datos.
Lo fundamental de este mapeo es un archivo de modelo (un "EOModel") que usted construye con una herramienta visual, ya sea EOModeler o el complemento EOModeler para Xcode . El mapeo funciona de la siguiente manera:
Puede crear modelos de datos basados en fuentes de datos existentes o puede crear modelos de datos desde cero, que luego utilizará 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 la base de datos que no se ve en otras herramientas y permite utilizar el mismo modelo para acceder a diferentes bases de datos de proveedores e incluso permite relaciones entre diferentes bases de datos de 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 definidos en memoria. Luego rastrea los cambios en estos objetos y puede revertir esos cambios a pedido, como cuando un usuario realiza un comando de deshacer. Luego, cuando llega el momento de guardar los cambios en los datos de la aplicación, esta archiva los objetos en las fuentes de datos subyacentes.
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 ciertas características de un objeto Persona más genérico, como nombre, dirección y 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 admiten explícitamente la herencia. Sin embargo, al utilizar Enterprise Objects, puede crear modelos de datos que reflejen jerarquías de objetos. Es decir, puede diseñar tablas de bases 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.
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 diferencia a un EO de otros objetos es que los datos de su 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 había 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 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 objetos 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 que esto afecte el código del desarrollador. Esto confiere a Enterprise Objects un alto grado de reutilización.
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.
EOF admite SQL personalizado; contextos de edición compartidos; contextos de edición anidados; y búsqueda 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 EOModelGroup: la clase NSMangedObjectModel proporciona métodos para fusionar modelos de modelos existentes y para recuperar modelos fusionados de paquetes.
Core Data admite propiedades recuperadas; múltiples configuraciones dentro de un modelo de objetos gestionados; 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 propiedades y advertencias de validación; y el uso de predicados para la validación de propiedades. Estas características de la implementación original de Objective-C no son compatibles con la implementación de Java.