Re: Invoice program made in Objective c/Cocoa
Re: Invoice program made in Objective c/Cocoa
- Subject: Re: Invoice program made in Objective c/Cocoa
- From: Andreas Grosam <email@hidden>
- Date: Sat, 16 May 2009 14:48:38 +0200
On May 16, 2009, at 12:33 PM, Kyle Sluder wrote:
On Sat, May 16, 2009 at 5:48 AM, Andreas Grosam
<email@hidden> wrote:
Even more, it would in no way an exaggerated asset if it would
seamlessly
support to create application servers, leveraging DO, and creating
web
applications with minimal code changes starting from a single- or a
client
server model.
There is/was a technology for this called Enterprise Objects
Framework, from which Core Data is descended.
EOF is an Apple technology (and product) but otherwise it is not (not
any more) related to Cocoa. We could mention a dozen of other similar
frameworks which serves the same purpose on this and other platforms.
So, this is not an answer to the topic.
If this would be really true, any serious database application
could not use
Core Data. So, for what is it anyway? Storing the users preferences?
Creating your own local CD-collection application?
It's a persistence framework for desktop applications. Why must these
things be relegated to boring server-side apps? Now any application
gets a persistence framework for pretty much free. If you want
client/server, you're more than welcome to implement it or use a
framework that does it for you, but Core Data is not that framework.
In fact, Core Data has features that are also required for a multi
user approach. So, Core Data could be that framework, but it is not
(yet) tailored to support additional parts that finally implement a
multi user approach.
Besides, you should probably avoid serializing objects over a network
connection, it tends to be a very tricky endeavor, especially in
Objective-C.
Thanks for this warning. I already suspected that this is not as
"seamless" as it is already implemented elsewhere. ;)
I really can‘t believe this. It would be a great faux-pas! Do I
really miss
something? Is this limitation anywhere documented?
You say "limitation," the rest of the world says "design principle."
A design "principle"? Call it how you like but a database application
does not have this principle. The opposite is true - it is an anti
principle, or in other words, any framework that supports any database
application shall not be single user, single transaction context, non-
transactional.
This design "principle" severely limits the number of useful
applications.
The OPs requirements are "database application". So, according the
principle, Core Data is not appropriate for database applications,
and this raises the question for what else.
IMHO, it is worth to figure out if Core Data possibly *CAN* be used to
implement a Client/Server architecture.
Regards
Andreas
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden