Re: Cocoa Technologies Back-Story?
Re: Cocoa Technologies Back-Story?
- Subject: Re: Cocoa Technologies Back-Story?
- From: "Erik M. Buck" <email@hidden>
- Date: Sat, 30 Apr 2005 18:41:52 -0400
>Bindings:
>Whose idea was it try to eliminate the controller layer?
This too goes back to early Smalltalk work.
>Is there a history to trying to do this outside of Apple/NeXT?
Microsoft tried with DDE which I think stands for "Dynamic Data
Exchange" and the DoExchnage() features of MFC classes. There is some
support for automating these controller tasks in MS Visual Studio's
various "editors." Borland's Delphi, IBMs Smalltalk, Java, and C++
environments provide some automation. Ref: Microsoft's "Managed
Objects" .Net and C# seem to emphasize bindings like capabilities, but
I admit to having only casually explored .Net.
Some here might even argue that "signals & slots" automates some of
this in the same way "Targets and Actions" automates some of it. e.g.
Automated menu validation and simple connection of menu items to
objects eliminates a lot of controller code needed in other
environments.
>If so, do those approaches go by a different name?
>Do other platforms that don't have the benefit of key/value runtime
>introspection have a different solution to this kind of thing, or do
>they all use some kind of "yucky controller layer" ?
Yes, yes, and yes.
>Core Data:
>Is this database technology?
I seems similar to "Enterprise Objects Framework" (EOF) which Apple
still sells. EOF has more of a database centric view of the world than
CoreData.
>Is it "normal" to apply database technology to application design?
My guess is that 90+ percent of all software written is database and
business automation related. In that context, I would say not using
database technology influenced design is abnormal ;)
>Is there a debate about whether database "entity modeling" should be
>used in desktop applications?
Yes. I think Apple engineers would be the first to tell you that
CoreData is not the best solution to every model layer problem just
like the MVC pattern is not best applied to all application designs.
However, in both cases, the techniques are applicable to a surprisingly
broad range of applications.
>Should I feel warm and fuzzy about designing my application's model
>this way instead of in a more "dictionary-oriented" way?
No. The view of objects as dictionaries is just one implementation
technique, and it is useful but not very often the best solution IMHO
:) I would say a better contrast would be entity relation diagrams and
traditional OO decomposition.
>Are there times that I should favor "traditional" model design over
>this new format?
Yes. If the application is primarily computational instead of data
management oriented, I would probably not choose CoreData. I doubt
Core Data can substantially automate or improve a ray tracer, a fractal
generator, a PDF viewer, an industrial equipment controller, a low
level DVD burner, many games, etc. In fact, I am starting to think
that "real time" and Core Data are mutually exclusive.
I can't wait to see Apple's Sketch example re-implemented with
CoreData. It could be Cool!
>Is good database design equivalent to good application model design?
No.
Apple has added a powerful tool to our tool boxes. That is all. The
tool is not particularly original (To the CS field or even to Apple) in
concept, but it probably is in implementation.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden