I'm going to can the excerpts from other posts for a moment and bring
this back around to helping to solve Cocoa development problems.
Though you might have to scroll down a bit to get there... :)
There are actually four different specific technical issues that have
been discussed concretely or alluded to:
(1) object graph management -- managing a bunch of objects with
relatively complex connectivity between, including ability to do
validation, undo tracking, user interface bindings, change
propagation, grouping/filtering/organizing of subgraphs, etc...
(2) persistency of the object graph; could be to memory, to permanent
storage atomically, or to permanent storage incrementally.
(3) client/server style interaction with a remote store for pushing/
pulling bits of object graph to some server with multi-user access
that includes ability to do conflict management, change integration,
stale data detection, etc...
(4) mapping between the object graph and a schema that is defined
outside of the framework that offers (1), (2), and (3).
----
Currently, Cocoa has (1) and (2) in the form of Core Data. Cocoa has
that in spades. Having worked with many different object persistency
management layers over the years (including designing & implementing a
few), I'm pretty sure Cocoa has the best quality (1) that isn't a
highly specific solution within a limited problem domain.
(1) is also one of the most difficult problems to solve, especially
when aiming for a general purpose solution widely applicable to many
different styles of applications.
As for (2), the incremental storage part is what is interesting. Core
Data solves that through the use of a SQLite backing store. SQL based
data storage is the standard means of achieving incremental retrieval
and storage of data in our industry. There are alternatives, but none
that have gained anything near the pervasiveness of SQL based
technologies. SQLite is ideal for desktop use and it isn't really
limited to single-user, simply limited to single machine (sticking a
SQLite database on a network filesystem and trying to go multi-user
is... just don't do it). Anyone who claims that SQLite is a toy
database hasn't really looked at SQLite; it is a pretty darned
amazing bit of code, that.
Now, what Core Data does not offer is (3) and (4). In the case of
(3), the assumption would be that -- like with the SQLite database --
Core Data would manage the entire schema of the database on the
server. Certainly, that would be useful to a subset of developers,
but how many? In studying the problem, I come up with "not that
many". In almost cases where I have looked at problems that required
client/server database access, one of the requirements was to
interface with some kind of a reporting engine, web service/server, or
something else that wants to go trolling through the data store and,
more likely, edit stuff.
At that point, the choices are to fully document the schema and
implement a whole bunch more code that tries to detect when someone
has done something wrong in the database. Combined with the need to
provide some kind of a means of making access to many different
vendor's databases transparent -- some of which have notoriously "odd"
implementations of the SQL spec -- make implementing (3) extremely
costly both in $$$ and engineering hours spent.
And for what gain? Most of the potential users of (3) will
immediately smack right up against the proprietary -- though
documented, maybe -- schema and find it not-applicable. "What? I
can't just integrate reporting tool X because it requires the schema
to be in THIS form? Fail!". That is, as soon as client/server stuff
is in the mix, the overall design often becomes so business-case
specific that the deployment can be thought of more as a "custom
software technology ecosystem" than "a server and an app in a box".
So that brings up (4). (4) is a really really really hard problem to
solve. Stunningly hard. (4) is the kind of stuff that PHDs are written
about and for which there are companies that sell very expensive
products that do nothing but (4).
---
But the lack of (4) or, even, (3) should not be a deterrent to using
CoreData within your application, necessarily. Do not underestimate
the value of (1). Of all of the complex data management applications
I have used that have underestimated (1) -- and that is most of them
that try to re-invent (1) -- they have all had really nasty, off data
destroying, bugs that make the user interface really painful to use.
What I have successfully used in the past (and will do so again, I'm
certain), is to use CoreData as a local cache between the remote data
server and my local Object Graph.
Thus, my client/server layer has been quite thin. It simply grabs
data from the remote server -- in my case, I have used XML-RPC, but
using a SQL client/server would be no different -- and converts it
into the various entities to be shoved into the local CoreData store.
For propagating changes back, CoreData has a complete set of hooks for
figuring out exactly what has changed in the local store (see the
notifications on the various CoreData classes).
For simplicity's sake, I have generally used an in-memory store for my
local Core Data cache of the remote state. Very fast and
automatically resets every time the app is re-launched (or I recreate
the stack caching the connection data). However, you could use a
SQLite store for the cache and, thus, have the foundations for
creating an offline cache / offline editing type solution.
However, this brings up (5) :) -- conflict management, resolution, and
merging. It is a hard problem. Don't underestimate it.
b.bum
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
