Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
- Subject: Cocoa/EOF for non-enterprise apps Re: proof of cocoa superiority?
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 12 Jun 2001 08:59:39 -0400
If your toolbox contains nothing but a hammer...
.... all the problems look like nails.
I'm certainly not going to make any kind of a claim that EOF isn't
anything but the best tool in the world for building 2 tier and 3 tier
applications that use a relational-- or, at least, fixed structure
tables-- as a backing store. It is. It kicks major butt. Any
developer who still thinks it is necessary to write SQL by hand as a
normal part of n-tier app development is wwwaaayyy behind the times....
However, that does not mean EOF is an appropriate solution for every app
out there. Specifically, for applications targeted at the consumer
market, it very likely is not appropriate to use EOF as a solution for
persistency. I.e. EOF is not a good replacement for the traditional
multi-document UI that a product like, say, OmniGraffle,
GraphicConverter, or Create. Nor it is appropriate to apps that are
seemingly database centric like, say, iTunes or the Finder.
Apple is aware that some kind of a generic persistency solution
completely different from EOF needs to be provided to the developer.
Ernie P. repeated this point at several sessions at WWDC.
EOF isn't really appropriate to environments where one is trying to
persist a directed graph of objects where both the graph's connectivity
and the object contents need to be relatively flexible. The whole
notion of having a Model that provides a formal mapping between a flat
table of fixed structure and a flat object is counter to the persistency
problem faced by most developers targeting typically standalone
applications. Furthermore, the notion of relationship as defined by
EO-- that of a relationship of a fixed type with a fixed destination--
does not map to the typically much more malleable object graph produced
by desktop applications.
Certainly, there is a tremendous amount of value within and knowledge to
be gained from the feature set of EOF, but that does not make it a good
tool to solve the generic desktop persistency problem.
b.bum
BTW: Stating that the "power of EOF for desktop apps" is not currently
available is inaccurate. Have you actually tried working with the pure
Java EOF in WO 5.x targeted to building Cocoa applications? It works
fine. There are some rough edges at the adaptor level, but they are
no worse than the rough edges in the native adators and it is extremely
refreshing to be able to pop off to Sybase's or Oracle's web site, grab
the latest and greatest JDBC adaptors, and have them *just work*.
Obviously, a remaining issue is one of licensing and it will be
interesting to see how Apple addresses that issue. Let's hope it is
handled with a bit more finesse than some of the licensing events in
past history....
On Tuesday, June 12, 2001, at 05:47 AM, cocoa-dev-
email@hidden wrote:
I'm not going to cry over DP, since I never developed on NeXT, and
Phone
Kit doesn't sound like anything I'll miss, but whose bright idea over
there
in Cupertino was it to remove EOF from Cocoa and make it only a
WebObjects
thing? It's like Apple doesn't WANT to be involed in the Enterprise
application space, which is really a shame. <sigh>. The things I could
do
with Cocoa an EOF...
Jeff, try telling it to email@hidden. The more customers say so, the
better the chances of us someday regaining the power of EOF for desktop
apps.