EOF (was Re: Cocoa CGI)
EOF (was Re: Cocoa CGI)
- Subject: EOF (was Re: Cocoa CGI)
- From: mmalcolm crawford <email@hidden>
- Date: Fri, 18 May 2001 05:24:16 +0100
I wrote:
Persistent Objects Framework
I've had some interest in this, so by way of a quick introduction to EOF
here's a concatenation of two of the emails I sent to someone to try to
give an idea of what this layer is about. Sorry for being lazy, I
really should do the topic greater justice...
Basically EOF provides a means of archiving objects.
The easiest way to think about this is probably in terms of a database:
If you're writing an OO application, it might be convenient to be able
to get records from a database and have them represented in your app as
an object. E.g. you might have an EMPLOYEE table in your database, rows
from the database might be represented in your app by instances of an
Employee class. If you add, delete or make changes to the employees in
your app, you want to have those changes reflected in the database.
Or at least this is the traditional perspective on the situation...
*really* how you probably want to think about it is that you have an app
which allows you to make changes to a collection of employee objects,
and these objects happen to persist beyond the lifetime of the app. And
in a fashion that makes it easy for a number of people to administer
these employees.
EOF allows you to take the latter perspective.
It doesn't have to work with a database, but that's the most common
object store.
But it's a lot more than that! :-)
For one thing there's the EOEditingContext (EC), which manages a
collection of enterprise objects (EOs)...
... when you fetch rows from the database, they're registered with the
EC, which then duly notes any changes you make to them. If you add or
delete EOs, the EC notices this, and when you save it updates the
database appropriately.
It also makes sure that if you fetch an EO more than once (e.g. you
might fetch all Employees in the Sales department, and later all
Employees whose salary is more than $50kpa, and Jo Smith is in both
sets) that you only ever have one EO representing a given row in the
database (uniqueness constraint).
It manages relationships for you too (I believe this is unique to EOF,
and something Apple has a patent on...?). Suppose you fetch all the
Departments from the database. If a Department has a to-many
relationship to Employees (an NSArray instance variable called
"employees"), you might expect then that all the employees would also
have to be fetched to make up the employees array. Not so; they
"employees" relationships are represented by "faults" and will only be
fetched (automatically, and completely transparently to you) if you ask
the Department for its employees.
Conversely, if the Employee has a relationship to a Department
("department"), and you fetch a number of employees, you won't get the
Departments until you ask an employee which department they belong to.
When you do, though, and the Department is fetched, not only is the
"fault" resolved for that one employee, but also for any other employee
you've fetched which belongs to the same department -- due to the
uniqueness constraint.
EOF also manages conflict detection for you, through snapshotting. If
you've fetched a record from the database, unless you SELECT FOR UPDATE
and lock the row, someone else might change it under you. But locking
the row is "expensive", and potentially dangerous, especially on a web
app -- the app might crash, or on the web the user's browser might
crash, or they might just stop browsing (since the web is stateless
you'd never know). If you don't lock the row, though, how do you know
if the data has changed?
EOF automatically takes a snapshot of all records you fetch, recording
their attribute values at the time you got them. When you come to save
changes, the current DB values are compared with the values in the
snapshots -- if they differ, clearly someone else has updated the
database while you were looking at the data, and an exception is
raised. (You have a number of ways of dealing with this.)
This just touches the surface of EOF's capabilities, but I hope gives a
feeling for the power of the framework.
mmalc.
| References: | |
| | >Re: Cocoa CGI (From: mmalcolm crawford <email@hidden>) |