Платформа Enterprise Objects Framework , или чаще просто EOF , была представлена NeXT в 1994 году как новаторский продукт объектно-реляционного сопоставления для ее платформ разработки NeXTSTEP и OpenStep . EOF абстрагирует процесс взаимодействия с реляционной базой данных путем сопоставления строк базы данных с объектами Java или Objective-C . Это в значительной степени избавляет разработчиков от необходимости писать низкоуровневый код SQL .
EOF пользовалась определенным успехом в середине 1990-х среди финансовых организаций, которых привлекли преимущества быстрой разработки приложений объектно-ориентированной платформы NeXT. После слияния Apple Inc с NeXT в 1996 году EOF превратился в полностью интегрированную часть WebObjects , сервера приложений, также изначально принадлежавшего NeXT. Многие из основных концепций EOF вновь появились как часть Core Data , которая дополнительно абстрагирует базовые форматы данных, чтобы позволить им быть основанными на хранилищах, отличных от SQL.
История [ править ]
В начале 1990-х годов NeXT Computer осознала, что подключение к базам данных важно для большинства предприятий, но при этом потенциально сложно. Каждый источник данных имеет свой язык доступа к данным (или API ), что увеличивает затраты на изучение и использование продукта каждого поставщика. Инженеры NeXT хотели применить преимущества объектно-ориентированного программирования , заставив объекты «разговаривать» с реляционными базами данных. Поскольку эти две технологии очень разные, решение заключалось в создании уровня абстракции, изолирующего разработчиков от написания низкоуровневого процедурного кода ( SQL ), специфичного для каждого источника данных.
Первая попытка была предпринята в 1992 году, когда был выпущен пакет Database Kit (DBKit), который обернул объектно-ориентированную структуру вокруг любой базы данных. К сожалению, NEXTSTEP в то время был недостаточно мощным, а DBKit имел серьезные недостатки в конструкции.
Вторая попытка NeXT была предпринята в 1994 году с версией 1 Enterprise Objects Framework (EOF), полностью переписанной, которая была гораздо более модульной и совместимой с OpenStep . EOF 1.0 был первым продуктом, выпущенным NeXT с использованием Foundation Kit, и представил сообществу разработчиков автоматически выпускаемые объекты. Команда разработчиков на тот момент состояла всего из четырех человек: Джек Гринфилд, Рич Уильямсон, Линус Апсон и Дэн Уилхайт. Версия EOF 2.0, выпущенная в конце 1995 года, доработала архитектуру, добавив контекст редактирования. На тот момент команда разработчиков состояла из Дэна Уилхайта, Крейга Федериги , Эрика Нояу и Чарли Кляйсснера.
EOF добился скромного уровня популярности в сообществе финансового программирования в середине 1990-х годов, но стал самостоятельным с появлением Всемирной паутины и концепции веб-приложений . Было ясно, что EOF может помочь компаниям подключить свои унаследованные базы данных к Интернету без какой-либо перезаписи этих данных. С добавлением фреймворков для управления состоянием, балансировки нагрузки и генерации динамического HTML, NeXT смогла запустить в 1996 году первый объектно-ориентированный сервер веб-приложений, WebObjects , с EOF в своей основе.
В 2000 году , Apple Inc. (который слился с NeXT) официально упала EOF как отдельный продукт, а это означает , что разработчики не смогут использовать его для создания настольных приложений для предстоящего Mac OS X . Тем не менее, он останется неотъемлемой частью нового выпуска WebObjects. WebObjects 5, выпущенный в 2001 году, имел важное значение тем, что его фреймворки были перенесены с родного языка программирования Objective-C на язык Java . Критики этого изменения утверждают, что большая часть возможностей EOF была побочным эффектом его корней Objective-C, и что EOF потерял красоту и простоту, которые когда-то были. Сторонние инструменты, такие как EOGenerator , помогают восполнить недостатки, вызванные Java (в основном из-за потерикатегории ).
Кодовая база Objective-C была повторно представлена разработчикам настольных приложений с некоторыми модификациями как Core Data , часть Apple Cocoa API , с выпуском Mac OS X Tiger в апреле 2005 года.
Как работает EOF [ править ]
Enterprise Objects предоставляет инструменты и структуры для объектно-реляционного сопоставления. Технология специализируется на предоставлении механизмов для извлечения данных из различных источников данных, таких как реляционные базы данных через каталоги JDBC и JNDI, и механизмов для передачи данных обратно в эти источники данных. Эти механизмы разработаны с использованием многоуровневого абстрактного подхода, который позволяет разработчикам думать об извлечении данных и обязательствах на более высоком уровне, чем конкретный источник данных или поставщик источника данных.
Центральным элементом этого сопоставления является файл модели («EOModel»), который вы создаете с помощью визуального инструмента - либо EOModeler, либо подключаемого модуля EOModeler к Xcode . Отображение работает следующим образом:
- Таблицы базы данных сопоставляются с классами.
- Столбцы базы данных сопоставляются с атрибутами класса.
- Строки базы данных сопоставляются с объектами (или экземплярами классов).
Вы можете создавать модели данных на основе существующих источников данных или вы можете создавать модели данных с нуля, которые затем используете для создания структур данных (таблиц, столбцов, объединений) в источнике данных. В результате записи базы данных можно переносить в объекты Java.
Преимущество использования моделей данных состоит в том, что приложения изолированы от особенностей источников данных, к которым они обращаются. Такое разделение бизнес-логики приложения от логики базы данных позволяет разработчикам изменять базу данных, к которой обращается приложение, без необходимости изменять приложение.
EOF обеспечивает уровень прозрачности базы данных, недоступный в других инструментах, и позволяет использовать одну и ту же модель для доступа к базам данных разных поставщиков и даже позволяет устанавливать отношения между базами данных разных поставщиков без изменения исходного кода.
Его сила заключается в представлении базовых источников данных в виде управляемых графов постоянных объектов. Проще говоря, это означает, что он организует уровень модели приложения в набор определенных объектов данных в памяти. Затем он отслеживает изменения этих объектов и может отменить эти изменения по запросу, например, когда пользователь выполняет команду отмены. Затем, когда приходит время сохранить изменения в данных приложения, оно архивирует объекты в базовые источники данных.
Использование наследования [ править ]
При проектировании корпоративных объектов разработчики могут использовать объектно-ориентированную функцию, известную как наследование . Например, объект Customer и объект Employee могут наследовать определенные характеристики от более общего объекта Person, такие как имя, адрес и номер телефона. Хотя такое мышление присуще объектно-ориентированному дизайну, реляционные базы данных не имеют явной поддержки наследования. Однако с помощью корпоративных объектов вы можете создавать модели данных, отражающие иерархии объектов. То есть вы можете проектировать таблицы базы данных для поддержки наследования, также создавая корпоративные объекты, которые сопоставляются с несколькими таблицами или определенными представлениями таблицы базы данных.
Что такое корпоративный объект (EO)? [ редактировать ]
Корпоративный объект аналогичен тому, что в объектно-ориентированном программировании часто называют бизнес-объектом - классом, который моделирует физический или концептуальный объект в бизнес-области (например, клиент, заказ, товар и т. Д.). Что отличает EO от других объектов, так это то, что данные его экземпляра отображаются в хранилище данных. Обычно корпоративный объект содержит пары ключ-значение, которые представляют строку в реляционной базе данных. Ключ - это в основном имя столбца, а значение - это то, что было в этой строке в базе данных. Таким образом, можно сказать, что свойства EO сохраняются после срока службы любого конкретного запущенного приложения.
Точнее, Enterprise Object - это экземпляр класса, реализующего интерфейс com.webobjects.eocontrol.EOEnterpriseObject.
У корпоративного объекта есть соответствующая модель (называемая EOModel), которая определяет соответствие между объектной моделью класса и схемой базы данных. Однако корпоративный объект явно не знает о своей модели. Этот уровень абстракции означает, что можно менять поставщиков баз данных, не влияя на код разработчика. Это дает корпоративным объектам высокую степень повторного использования.
EOF и основные данные [ править ]
Несмотря на их общее происхождение, две технологии разошлись, и каждая технология сохранила подмножество функций исходной кодовой базы Objective-C, добавив при этом некоторые новые функции.
Функции, поддерживаемые только EOF [ править ]
EOF поддерживает настраиваемый SQL; общие контексты редактирования; вложенные контексты редактирования; а также предварительная выборка и пакетное исправление отношений - все функции исходной реализации Objective-C, не поддерживаемые Core Data. Core Data также не предоставляет эквивалента EOModelGroup - класс NSManagedObjectModel предоставляет методы для объединения моделей из существующих моделей и для извлечения объединенных моделей из пакетов.
Функции, поддерживаемые только Core Data [ править ]
Core Data поддерживает извлекаемые свойства; несколько конфигураций в рамках управляемой объектной модели; местные магазины; и агрегирование хранилищ (данные для данного объекта могут быть распределены по нескольким хранилищам); настройка и локализация имен свойств и предупреждений проверки; и использование предикатов для проверки свойств. Эти функции исходной реализации Objective-C не поддерживаются реализацией Java.
Внешние ссылки [ править ]
- статья в linuxjournal о GDL2
