On 16/10/2013, at 13:11, Andrew Satori <d...@druware.com> wrote:

> At the root of things, what I think we are really discussing is a model not 
> about CoreData, but one about CoreWebServices.  Could we build a framework 
> that let's you model your data in a modeler, and it publishes the model to a 
> RESTful web service via JSON?  Absolutely, but ODBC probably isn't the right 
> vehicle.  In this instance, you could in fact even do it in CoreData (I 
> wouldn't but you certainly could).  

That's what I am talking about!

For sure, ODBC is not the answer here, nor direct client access to the 
database, as we need something to manage locking and concurrency, as you said 
-- unless the RDBMS can do that. Is there such a beast?

The reason we look to CoreData as a Holy Grail kind of thing is that it makes 
it just too easy (before it gets complicated, which is a real issue): just 
model the data, write some custom accessors (if needed) and validators (if the 
standard ones don't suffice) and bind the interface elements.

So, it doesn't have to be CoreData, but it has to be something as simple as 
that. Well, not *that* simple -- as enterprise applications are not as simple 
as, let's say, a recipe management app or even Delicious Library!

I studied two options in the past:

1. Use CoreData for the client and server. The server would be a command-line 
utility and would exchange data with the client through XML or JSON 
(implementing a RESTful web service). This way, the model (and some other code) 
can be shared between the two components, but SQLite is not so robust for 
multi-user applications;

2. Use something else for the server (I use Project WOnder, which is, simply 
put, a *huge* collection of enhancements to WebObjects) to implement a RESTful 
web service, and AFIncrementalStore (a CoreData store which persists data 
through a web service) on the client. This makes it easy to use powerful 
RDBMSs, but you have to manage the two "identical" data models.

I stuck with option 2. It's not my dream toolset, but works well.


Cheers,
Flavio
_______________________________________________

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to