Marco de objetos empresariales

El Enterprise Objects Framework , o simplemente EOF , fue presentado por NeXT en 1994 como un producto pionero de mapeo objeto-relacional para sus plataformas de desarrollo NeXTSTEP y OpenStep . EOF abstrae el proceso de interacción con una base de datos relacional al mapear las 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 gozó de cierto éxito en un nicho de mercado a mediados de la década de 1990 entre las instituciones financieras, atraídas por las ventajas de desarrollo rápido de aplicaciones que ofrecía la plataforma orientada a objetos de NeXT. Desde la fusión de Apple Inc. con NeXT en 1996, EOF se ha integrado completamente en WebObjects , un servidor de aplicaciones también originario de NeXT. Muchos de los conceptos fundamentales de EOF resurgieron como parte de Core Data , que abstrae aún más los formatos de datos subyacentes para permitir su uso con bases de datos distintas de SQL.

A principios de la década de 1990, NeXT Computer reconoció que la conexión a bases de datos era esencial para la mayoría de las empresas, pero también potencialmente compleja. Cada fuente de datos tiene un lenguaje de acceso a datos (o API ) diferente, lo que incrementa los costos de aprendizaje y uso del producto de cada proveedor. Los ingenieros de NeXT querían aprovechar las ventajas de la programación orientada a objetos , logrando que los objetos se comunicaran con las bases de datos relacionales. Dado que ambas tecnologías son muy diferentes, la solución consistió en crear una capa de abstracción que evitara que los desarrolladores escribieran el código procedimental 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 integraba un marco de trabajo orientado a objetos en cualquier base de datos. Desafortunadamente, NEXTSTEP en aquel momento no era lo suficientemente potente y DBKit presentaba graves fallos de diseño.

El segundo intento de NeXT llegó en 1994 con la versión 1 de Enterprise Objects Framework (EOF), una reescritura completa 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 auto-lanzamiento a la comunidad de desarrolladores. El equipo de desarrollo en ese momento estaba formado por solo 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 compuesto por Dan Willhite, Craig Federighi , Eric Noyau y Charly Kleissner.

EOF alcanzó una popularidad moderada en la comunidad de programación financiera a mediados de la década de 1990, pero se consolidaría con la aparición de la World Wide Web y el concepto de aplicaciones web . Era evidente que EOF podía ayudar a las empresas a integrar sus bases de datos heredadas en la web sin necesidad de reescribir los datos. Con la incorporación de marcos de trabajo para la gestión de estado, el equilibrio de carga y la generación dinámica de HTML , NeXT pudo lanzar en 1996 el primer servidor de aplicaciones web orientado a objetos, WebObjects , con EOF como núcleo.

En 2000, Apple Inc. (que se había fusionado con NeXT) dejó de vender oficialmente EOF como producto independiente, lo que significaba que los desarrolladores no podrían usarlo para crear aplicaciones de escritorio para el futuro Mac OS X. Sin embargo, continuaría siendo una parte integral de una nueva versión importante de WebObjects. WebObjects 5, lanzado en 2001, fue significativo porque sus marcos de trabajo se habían portado de su lenguaje de programación nativo Objective-C al lenguaje Java . Los críticos de este cambio argumentan que gran parte del poder de EOF era un efecto secundario de sus raíces en Objective-C, y que EOF perdió la belleza o simplicidad que alguna vez tuvo. Herramientas de terceros, como EOGenerator , ayudan a llenar las deficiencias introducidas por Java (principalmente debido a 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.

Enterprise Objects proporciona herramientas y marcos de trabajo para el mapeo objeto-relacional. Esta tecnología se especializa en ofrecer mecanismos para recuperar datos de diversas fuentes, como bases de datos relacionales mediante directorios JDBC y JNDI , y mecanismos para guardar los datos en dichas fuentes. Estos mecanismos están diseñados con un enfoque abstracto y por capas que permite a los desarrolladores considerar la recuperación y la confirmación de datos a un nivel superior al de una fuente de datos o un proveedor específico.

Un elemento central de este mapeo es un archivo de modelo (un "EOModel") que se crea con una herramienta visual , ya sea EOModeler o el complemento de EOModeler para Xcode . El mapeo funciona de la siguiente manera:

• Las tablas de la base de datos están asignadas a clases.
• Las columnas de la base de datos se asignan a atributos de clase.
• Las filas de la base de datos se asignan a objetos (o instancias de clase).

Puedes crear modelos de datos a partir de fuentes de datos existentes o desde cero, para luego utilizarlos en la creación de estructuras de datos (tablas, columnas, uniones) en la fuente. De esta forma, los registros de la base de datos se pueden convertir en objetos Java.

La ventaja de usar modelos de datos radica en que las aplicaciones quedan aisladas de las particularidades de las fuentes de datos a las que acceden. Esta separación entre la lógica de negocio de la aplicación y la lógica de la base de datos permite a los desarrolladores modificar la base de datos a la que accede la aplicación sin necesidad de modificar la propia aplicación.

EOF proporciona un nivel de transparencia de la base de datos que no se encuentra en otras herramientas y permite utilizar el mismo modelo para acceder a bases de datos de diferentes proveedores, e incluso permite establecer relaciones entre bases de datos de diferentes proveedores sin modificar el código fuente.

Su potencia reside en exponer las fuentes de datos subyacentes como grafos gestionados de objetos persistentes. En términos sencillos, esto significa que organiza la capa del modelo de la aplicación en un conjunto de objetos de datos definidos en memoria. A continuación, realiza un seguimiento de los cambios en estos objetos y puede revertirlos bajo demanda, por ejemplo, cuando un usuario ejecuta un comando de deshacer. Posteriormente, cuando llega el momento de guardar los cambios en los datos de la aplicación, archiva los objetos en las fuentes de datos subyacentes.

Un objeto empresarial (EO) es análogo a lo que en programación orientada a objetos se conoce como objeto de negocio : una clase que modela un objeto físico o conceptual del dominio empresarial (por ejemplo, un cliente, un pedido, un artículo, etc.). La diferencia entre un EO y otros objetos radica en que sus datos de instancia se corresponden con 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 el contenido de esa fila en la base de datos. Por lo tanto, se puede afirmar que las propiedades de un EO persisten más allá de la vida útil de cualquier aplicación en ejecución.

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 (denominado EOModel) que define la correspondencia 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 permite cambiar de proveedor de bases de datos sin que ello afecte al código del desarrollador. Esto confiere a los objetos empresariales un alto grado de reutilización.

A pesar de sus orígenes comunes, las dos tecnologías divergieron, conservando cada una un subconjunto de las características del código base original de Objective-C, a la vez que añadieron algunas características nuevas.

• Artículo en Linux Journal sobre GDL2