[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    JPA properties
From:       zonski () gmail ! com (Daniel Zwolenski)
Date:       2012-10-30 22:41:06
Message-ID: CANbPsPwXnDr3nSfrgPBbkyKh0nkF4zH1tfbbk=pZPf=ZdXwzXQ () mail ! gmail ! com
[Download RAW message or body]

Yea, I was following the thread started by your original question regarding
"properties on server side JPA beans" and my comments are all in that
context. I just stopped saying the word "server" which I think confused
things. I think observable properties on "server-side JPA beans" are a bad
idea for all the reasons outlined by Tom S plus my own.

The "don't call the database from the client" was also in the same context
of client-server - i.e. it's not a great idea to 'fake' a client-server
setup by using your database as the 'server'. This is due mainly to reasons
of security and performance (particularly with respect to multiple users)
but there are other reasons too.

Using a local, client-only database as a cache or to store settings, etc
(effectively an alternative to the file system) is definitely a valid use
case and one I use often. It's a very different situation to client-server
though: all calls are local; there's only one db user; the entire JPA
tree/cache "belongs" to your app instead of being shared; etc.

The argument for observable properties on your client-side JPA cache data
is more open to debate than the server side one in my opinion.

I can't see anything these properties add that's useful at the JPA layer
but I imagine most people would want to do it so they can reuse their "view
model" and just serialize it. I tend not to do this, I'd have POJOs
specifically representing the JPA cache beans and have different (but
similar) observable models for the 'view' - standard
'decoupling'/'separation of concerns', a lot more work but more testable
and maintainable. I'm that sort of coder though, and there are
people religiously bent the other way.

As always it's a case of "fit-for-purpose" plus a good dash of personal
preference thrown in for added flavour.

For the architectures I use, a framework that could more easily map from
one bean to another (observable or otherwise) would be extremely useful.
Something more in line with your 'BlackMagic' idea (but I think it is too
simple) - a kind of bean-to-bean binding approach, with support for
observables a bonus. I'd be interested in work shopping ideas on this if
anyone wants to.

Not sure this is a 'core' JFX problem though (since I've had the same thing
come up in Swing, GWT, Webservices and pretty much everywhere in Java).
Seems like something that could/should be an external library?




On Wed, Oct 31, 2012 at 2:48 AM, Richard Bair <richard.bair at oracle.com>wrote:

> > Fair enough. Calling directly onto a database from the client is probably
> > not an approach I would go for too often or recommend for a lot of use
> > cases, but hey, if it works for you, great.
>
> In particular, it is not uncommon for client apps to want to stash some
> data into, say, a local berkeley database. The iBank app for Mac OS X does
> exactly this. I wrote a little app the used JPA and mapped beans over their
> database structure for an alternate UI. Being able to do this on the client
> side is excessively common when you're talking about native bundled
> applications that aren't talking to a backend (more common in the consumer
> space), or one where although it talks to a backend system, it maintains a
> full copy of data locally.
>
> Richard

[prev in list] [next in list] [prev in thread] [next in thread]