Re: Rant: Why I hate Java Client
Re: Rant: Why I hate Java Client
- Subject: Re: Rant: Why I hate Java Client
- From: Ian Joyner <email@hidden>
- Date: Sat, 23 Feb 2008 11:52:58 +1100
On 23/02/2008, at 12:29 AM, Pierce T. Wetter III wrote:
On Feb 21, 2008, at 12:57 PM, Florijan Stamenkovic wrote:
Pierce,
Most of your arguments are valid only when talking about D2JC. And
I actually agree with many of them, that's why I never used D2JC .
One correction however: JC as an architecture does not imply D2JC,
it implies a Java process running on the client machine. And when
talking about WOJC it implies a Java process running on the client
machine, connecting to a WO server. Sorry for being a hairsplitter
on this, but badmouthing WOJC because of the issues of D2JC is
slander, simply put. It's like saying computers are bad, just
because you are running Windows...
That's absolutely fair, and to be honest, I was mostly grousing
about our particular application which is D2JC. And really grousing
about its lack of design. And the fact that it doesn't build
naturally in Eclipse because no one has updated the config
correctly. Programming is 1/3rd design, 1/3rd programming, 1/3rd
testing, and if you skip on design, the other 2 parts just take
longer.
You are a heretic Pierce ;-) Agile programming says you write some
tests (2/3rds of the work), write some code to pass these tests
(1/3rd)... ship product, fix customer problems really fast so your
support looks responsive! (Don't get me too wrong, Agile has a lot of
good things about it, and I have probably mischaracterized it :-).)
Pierce
P.S.
However, I would say that no technology is a panacea, and when you
shove the internet between the "client" portion of your application
and the "server" portion of your application, its worth thinking
about what you're doing. WOJC isn't a bad architecture and Paolo's
XMLBindingForJavaClient stuff looks cool.
But JC is basically an implementation of the "Proxy" design
pattern. http://en.wikipedia.org/wiki/Proxy_pattern
That is, the client side objects function as proxies for the server
side objects. So far so good. But sometimes, the "Facade" pattern is
more appropriate: http://en.wikipedia.org/wiki/Façade_pattern
That is, its often good to have a Facade sitting in front of your
Model objects, turning the MVC model into FMVC. Then you can proxy
the lightweight Facade object instead of the Model object.
For instance, lets say you have a Model object as follows:
Movie Storage:
String name;
NSData GIANT_MULTI_GIGABYTE_BLOB;
Integer PrimaryKey;
If on the JC side, all you ever need is the name of the movie for a
popup that says "what movie do you wish to stream" then it makes
sense to have a facade object for just the data you need. So on the
JC side:
MovieNameReference:
String name;
Integer PrimaryKey
Prevents you from streaming GIANT_MULTI_GIGABYTE_BLOB down to the
JC side.
Of course, this was an artificial example, but it general, when
writing these sorts of apps, I always find it best to use a well
designed Proxy interface like WOJC with a well designed set of
Facade classes...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden