Das Unternehmensgegenstand-Fachwerk (oder allgemeiner, EOF) wurde von NeXT 1994 als ein den Weg bahnendes kartografisch darstellendes mit dem Gegenstandverwandtschaftsprodukt für seine Entwicklungsplattformen von NeXTSTEP und OpenStep eingeführt. Die EOF Auszüge der Prozess, mit einer Verwandtschaftsdatenbank aufeinander zu wirken, Datenbankreihen nach Java oder Objektive-C Gegenstände kartografisch darstellend. Das entlastet größtenteils Entwickler davon, auf niedriger Stufe SQL-Code zu schreiben. EOF hat etwas Nische-Erfolg Mitte der 1990er Jahre unter Finanzeinrichtungen genossen, die zu den schnellen Anwendungsentwicklungsvorteilen der objektorientierten Plattform von NeXT angezogen wurden. Seit der Fusion von Apple Inc mit NeXT 1996 hat sich EOF zu einem völlig einheitlichen Teil von WebObjects, ein Anwendungsserver auch ursprünglich von NeXT entwickelt.

Geschichte

Am Anfang der 1990er Jahre hat Computer von NeXT anerkannt, dass das Anschließen mit Datenbanken für die meisten Geschäfte notwendig und noch auch potenziell kompliziert war. Jede Datenquelle hat eine verschiedene Datenzugang-Sprache (oder API), die Kosten in die Höhe treibend, um das Produkt jedes Verkäufers zu erfahren und zu verwenden. Die Ingenieure von NeXT haben die Vorteile der objektorientierten Programmierung anwenden wollen, indem sie Gegenstände bekommen haben, mit Verwandtschaftsdatenbanken "zu sprechen". Da die zwei Technologien sehr verschieden sind, war die Lösung, eine Abstraktionsschicht zu schaffen, Entwickler davon isolierend, den auf niedriger Stufe Verfahrenscode zu jeder Datenquelle spezifischer (SQL) zu schreiben.

Der erste Versuch ist 1992 mit der Ausgabe von Database Kit (DBKit) gekommen, der ein objektorientiertes Fachwerk um jede Datenbank gewickelt hat. Leider war NEXTSTEP zurzeit nicht stark genug, und DBKit hatte ernste Designfehler.

Der zweite Versuch von NeXT ist 1994 mit der Version 1 von Enterprise Objects Framework (EOF) gekommen, ein ganzer schreiben um, der viel mehr modular war und vereinbarer OpenStep. EOF 1.0 war das erste von NeXT veröffentlichte Produkt mit dem Fundament-Bastelsatz und hat autoveröffentlichte Gegenstände in die Entwickler-Gemeinschaft eingeführt. Die Entwicklungsmannschaft war zurzeit nur vier Menschen: Jack Greenfield, Rich Williamson, Linus Upson und Dan Willhite. EOF 2.0, veröffentlicht gegen Ende 1995, hat weiter die Architektur raffiniert, den Redigieren-Zusammenhang einführend. An diesem Punkt hat die Entwicklungsmannschaft aus Dan Willhite, Craig Federighi, Eric Noyau und Charly Kleissner bestanden.

EOF hat ein bescheidenes Niveau der Beliebtheit in der Finanzprogrammiergemeinschaft Mitte der 1990er Jahre erreicht, aber es würde in sein eigenes mit dem Erscheinen des World Wide Web und dem Konzept von Webanwendungen eintreten. Es war klar, dass EOF Gesellschaften helfen konnte, ihre Vermächtnis-Datenbanken ins Web ohne jedes Neuschreiben davon Daten einzustecken. Mit der Hinzufügung des Fachwerks, um Zustandmanagement, das Lastausgleichen und die dynamische HTML-Generation zu tun, ist NeXT im Stande gewesen, den ersten objektorientierten Webanwendungsserver, WebObjects 1996 mit EOF an seinem Kern zu starten.

2000 hat Apple Inc. (der sich mit NeXT verschmolzen hatte) offiziell EOF als ein eigenständiges Produkt fallen lassen, meinend, dass Entwickler unfähig sein würden, es zu verwenden, um Tischanwendungen für den bevorstehenden Mac OS X zu schaffen. Es würde jedoch fortsetzen, ein integraler Bestandteil einer neuen Hauptausgabe von WebObjects zu sein. WebObjects 5, veröffentlicht 2001, war für die Tatsache bedeutend, dass sein Fachwerk von ihrer heimischen Objektiven-C Programmiersprache bis die javanische Sprache getragen worden war. Kritiker dieser Änderung behaupten, dass der grösste Teil der Macht von EOF eine Nebenwirkung seiner Objektiven-C Wurzeln war, und dass EOF die Schönheit oder Einfachheit verloren hat, die es einmal hatte. Drittwerkzeuge, wie EOGenerator, füllt Hilfe die Mängel, die durch Java (hauptsächlich wegen des Verlustes von Kategorien) eingeführt sind.

Die Objektive-C Codebasis wurde mit einigen Modifizierungen in Tischanwendungsentwickler als Kerndaten, ein Teil der Kakao-API des Apfels mit der Ausgabe von Mac OS X Tiger im April 2005 wiedereingeführt.

Wie EOF arbeitet

Unternehmensgegenstände stellen Werkzeuge und Fachwerk dafür zur Verfügung, mit dem Gegenstand Verwandtschafts-kartografisch darzustellen. Die Technologie spezialisiert sich auf die Versorgung von Mechanismen, Daten von verschiedenen Datenquellen, wie Verwandtschaftsdatenbanken über JDBC und JNDI Verzeichnisse und Mechanismen wiederzubekommen, Daten zurück zu jenen Datenquellen zu begehen. Diese Mechanismen werden in einem layered, abstrakte Annäherung entworfen, die Entwicklern erlaubt, an Datenwiederauffindung und Engagement an einem höheren Niveau zu denken, als eine spezifische Datenquelle oder Datenquellverkäufer.

Zentral dazu kartografisch darzustellen, ist eine Musterdatei (ein "EOModel"), dass Sie mit einem Sehwerkzeug - entweder EOModeler oder die EOModeler Einfügefunktion zu Xcode bauen. Die kartografisch darstellenden Arbeiten wie folgt:

• Datenbanktische werden zu Klassen kartografisch dargestellt.
• Datenbanksäulen werden kartografisch dargestellt, um Attribute zu klassifizieren.
• Datenbankreihen werden zu Gegenständen (oder Klassenbeispiele) kartografisch dargestellt.

Sie können auf vorhandenen Datenquellen gestützte Datenmodelle bauen, oder Sie können Datenmodelle von Kratzer bauen, den Sie dann verwenden, um Datenstrukturen zu schaffen (Tabellen, Säulen, schließt sich an) in einer Datenquelle. Das Ergebnis besteht darin, dass Datenbankaufzeichnungen in javanische Gegenstände umgestellt werden können.

Der Vorteil, Datenmodelle zu verwenden, besteht darin, dass Anwendungen von den Eigentümlichkeiten der Datenquellen isoliert werden, auf die sie zugreifen. Diese Trennung einer Geschäftslogik einer Anwendung von der Datenbanklogik erlaubt Entwicklern, die Datenbank eine Anwendung Zugänge zu ändern, ohne die Anwendung ändern zu müssen.

EOF stellt ein Niveau der Datenbankdurchsichtigkeit zur Verfügung, die nicht in anderen Werkzeugen gesehen ist, und erlaubt demselben Modell, verwendet zu werden, um auf verschiedene Verkäufer-Datenbanken zuzugreifen, und erlaubt sogar Beziehungen über verschiedene Verkäufer-Datenbanken, ohne Quellcode zu ändern.

Seine Macht kommt daraus, die zu Grunde liegenden Datenquellen als geführte Graphen von beharrlichen Gegenständen auszustellen. In einfachen Begriffen bedeutet das, dass es die Musterschicht der Anwendung in eine Reihe von definierten Datengegenständen im Gedächtnis organisiert. Es verfolgt dann Änderungen zu diesen Gegenständen und kann jene Änderungen auf Verlangen, solcher als umkehren, wenn ein Benutzer einen aufmachen Befehl durchführt. Dann, wenn es Zeit ist, um Änderungen zu den Daten der Anwendung zu sparen, archiviert es die Gegenstände zu den zu Grunde liegenden Datenquellen.

Das Verwenden des Erbes

Im Entwerfen von Unternehmensgegenstand-Entwicklern kann die objektorientierte als Erbe bekannte Eigenschaft stärken. Ein Kundengegenstand und ein Mitarbeitergegenstand könnten beide zum Beispiel bestimmte Eigenschaften von einem allgemeineren Person-Gegenstand, wie Name, Adresse und Telefonnummer erben. Während diese Art des Denkens dem objektorientierten Design innewohnend ist, haben Verwandtschaftsdatenbanken keine ausführliche Unterstützung für das Erbe. Jedoch, mit Unternehmensgegenständen, können Sie Datenmodelle bauen, die Gegenstand-Hierarchien widerspiegeln. D. h. Sie können entwickeln Datenbanktische, um Erbe zu unterstützen, indem es auch Unternehmen entworfen wird, wendet dass Karte gegen vielfache Tische oder besondere Ansichten von einem Datenbanktisch ein.

Was ist Enterprise Object (EO)?

Ein Unternehmensgegenstand ist dem analog, was häufig in der objektorientierten Programmierung als ein Geschäftsgegenstand - eine Klasse bekannt ist, die einen physischen oder begrifflichen Gegenstand im Geschäftsgebiet (z.B ein Kunde, eine Ordnung, ein Artikel, usw.) modelliert. Was einen EO verschiedenen von anderen Gegenständen macht, ist, dass seine Beispiel-Daten zu einem Datenladen kartografisch darstellen. Gewöhnlich enthält ein Unternehmensgegenstand Schlüsselwert-Paare, die eine Reihe in einer Verwandtschaftsdatenbank vertreten. Der Schlüssel ist grundsätzlich der Säulenname, und der Wert ist, was in dieser Reihe in der Datenbank war. So kann es gesagt werden, dass Eigenschaften eines EO außer dem Leben jeder besonderen laufenden Anwendung andauern.

Genauer ist ein Unternehmensgegenstand ein Beispiel einer Klasse, die com.webobjects.eocontrol.EOEnterpriseObject Schnittstelle durchführt.

Ein Unternehmensgegenstand hat ein entsprechendes Modell (hat einen EOModel genannt), der definiert zwischen dem Gegenstand-Modell der Klasse und dem Datenbankdiagramm kartografisch darzustellen. Jedoch weiß ein Unternehmensgegenstand über sein Modell nicht ausführlich. Dieses Niveau der Abstraktion bedeutet, dass Datenbankverkäufer ohne es geschaltet werden können, den Code des Entwicklers betreffend. Das gibt Unternehmensgegenständen einen hohen Grad der Wiederverwendbarkeit.

EOF und Kerndaten

Trotz ihrer allgemeinen Ursprünge sind die zwei Technologien mit jeder Technologie abgewichen, die eine Teilmenge der Eigenschaften der ursprünglichen Objektiven-C Codebasis behält, während sie einige neue Eigenschaften hinzugefügt haben.

Eigenschaften unterstützt nur durch EOF

EOF unterstützt kundenspezifischen SQL; geteilte Redigieren-Zusammenhänge; verschachtelte Redigieren-Zusammenhänge; und das Vorholen und Gruppe faulting Beziehungen, aller Eigenschaften der ursprünglichen Objektiven-C durch Kerndaten nicht unterstützten Durchführung. Kerndaten stellen auch die Entsprechung von EOModelGroup nicht zur Verfügung — die Klasse von NSManagedObjectModel stellt Methoden zur Verfügung, um Modelle von vorhandenen Modellen zu verschmelzen, und um verschmolzene Modelle von Bündeln wiederzubekommen.

Eigenschaften unterstützt nur durch Kerndaten

Kerndaten unterstützen herbeigeholte Eigenschaften; vielfache Konfigurationen innerhalb eines geführten Gegenstand-Modells; lokale Läden; und Lager-Ansammlung (können die Daten für eine gegebene Entität über vielfache Läden ausgebreitet werden); Anpassung und Lokalisierung von Eigentumsnamen und Gültigkeitserklärungswarnungen; und der Gebrauch von Prädikaten für die Eigentumsgültigkeitserklärung. Diese Eigenschaften der ursprünglichen Objektiven-C Durchführung werden durch die javanische Durchführung nicht unterstützt.

Außenverbindungen

• Apfeldokumentation: Einführung ins Verwenden EOModeler
• Apfeldokumentation: Unternehmensgegenstände
• Produktseite der Apple WebObjects
• Artikel in linuxjournal über GDL2