Skip to main content

JGoodies Binding Framework

78 replies [Last post]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
charles.armstrong
Offline
Joined: 2006-02-17
Points: 0

Rich,

Furthermore:

The short answer is you can't just getJavaBean and do
what you want with it. If you have drilled down through
a hierarchy you will have no idea what type it is.

So you either have to call its business methods by
reflection - but you don't even know which ones you
want to call in general.

So you have an instanceof statement with a clause for each
one of several hundred domain types - and then cast
it to that Domain type and then you can do what you want.
i.e. code from hell.

Is it becoming clearer?

Charles.

rbair
Offline
Joined: 2003-07-08
Points: 0

> Is it becoming clearer?

Sadly, no. And your ego isn't helping things.

> The short answer is you can't just getJavaBean and do what you want with it. If you have drilled down through a hierarchy you will have no idea what type it is.

Of course you do! How can you "drill down through a hierarchy" if you don't know what type of objects you're dealing with? If you know what type of object you are dealing with then you can *clearly* call getJavaBean and cast it to whatever object you are dealing with! Furthermore, if you use java 1.5 and generics, then the JavaBeanDataModel would be typed so that you know *exactly* what type of object you are dealing with.

> So you either have to call its business methods by
> reflection - but you don't even know which ones you
> want to call in general.

As amptly demonstrated above, this is simply not true.

> So you have an instanceof statement with a clause for each one of several hundred domain types - and then cast it to that Domain type and then you can do what you want. i.e. code from hell.

You seem to discount the fact that I have, indeed, accomplished this very thing, very simply. You would rather cast aspersions and FUD rather than talk about the facts. I have actually used such an architecture. Doesn't that count for something? Apparently not.

charles.armstrong
Offline
Joined: 2006-02-17
Points: 0

Ghost of Rich,

>Of course you do! How can you "drill down through a >hierarchy" if you don't know what type of objects you're >dealing with?

The user can drill down. By clicking a nested table. Then events fire.

Also code can drill down by successive getRecordAt(index)
calls.

>Furthermore, if you use java 1.5 and generics, then the >JavaBeanDataModel would be typed so that you know >*exactly* what type of object you are dealing with.

That would certainly improve the situation. However generics don't work with reflection.

I don't see how you can feel hard done by when
(1) Your initial post in this thread was incredibly rude
both in tone and not bothering to read the earlier posts.
(2) You asked me not to be obtuse. So I spelt it out.
You took offence.

Charles.

rbair
Offline
Joined: 2003-07-08
Points: 0

Charles,

I apologize if my original post was rude, I certainly didn't intend it to be so. I thought I usually include enough smiley faces in my posts to let folks see my jovial nature! As for bludgeoning Scott, I did admitted my error in the end, didn't I :). In retrospect, yes my position didn't make that much sense, but then I thought Scott was saying something he wasn't -- often the basis for misunderstandings. However, taking my postings to be unintelligent isn't really that fair since Scott and I ended up saying the same thing in the end (and were really saying the same thing all along just from different angles). You claimed skipping steps in explanations as a flaw of yours, and I think I can say the same for myself. As for my part, sorry for any offense. Next time I'm in London I'll take you up on that drink :)

Richard

Message was edited by: rbair

PS> Rootbeer of course!

rbair
Offline
Joined: 2003-07-08
Points: 0

Hey Aim,

> Actually, JDNC also supports binding to arbitrary
> "domain"
> objects (JavaBeans),so it's not limited just to
> RowSet. Albeit, our
> current JavaBean support is very primitive, and we
> need to improve
> our support for nested objects and collections.
>
> Aim

To bolster your position even more, JDNC doesn't even HAVE a RowSetDataModel yet (unless you guys snuck one in during the past week :))! JDNC is definately not designed with only sql in mind.

Richard

Patrick Wright

Scott

[snip]

> I think that what Karsten is doing is a subset of what JDNC is trying to
> achieve. My comment was just merely that having a half dozen projects all
> working towards the goal of transparent data binding, but in incompatible
> ways, will only achieve fragmentation.
>

I think your point is well taken, but one alternate view is that a
strength of Java is that there is an ecosystem of libraries--from the JDK,
commercial companies, and OSS/FS. I personally think the whole Java
community benefits from the competition, until the community naturally
gravitates towards one or two solutions. Sun's practice seems to be to
watch this happen and when necessary, step forward to bless one or two
approaches/APIs, as happened with the XML kit...

It is disconcerting when there are these multiple kits to choose from, but
a vibrant field of experimentation benefits us all in the long run.

Just my thoughts
Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Amy Fowler

jdnc-interest@javadesktop.org wrote:

> I don't agree that the two approaches have similar goals.
>
> In JDNC you have a Rowset, so persistence is trivial. This
> works well for simple projects.
>
> In JGoodies you have a rich client Object Model, but you
> then have to deal with all the issues of mapping these
> client side Objects to a relational database. So you have
> to have lots of SQL etc in your property change listeners.
> So this isn't for the faint hearted.

Actually, JDNC also supports binding to arbitrary "domain"
objects (JavaBeans),so it's not limited just to RowSet. Albeit, our
current JavaBean support is very primitive, and we need to improve
our support for nested objects and collections.

Aim

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

charles.armstrong
Offline
Joined: 2006-02-17
Points: 0

>Actually, JDNC also supports binding to arbitrary "domain"
>objects (JavaBeans),so it's not limited just to RowSet. >Albeit, our
>current JavaBean support is very primitive, and we need to >improve our support for nested objects and collections.

Aim,

I think you would need Strong typing before the current
API would be applicable for Domain Models, which would
mean a substantial redesign. Types are tke key abstraction
in Domain models.

Even then you are still left with the problem issue which is persistence. Serializing beans always run into version control problems - so you still have to map the beans to
a relational database.

I can't really see anyone using JDNC with Beans.

Hope I'm wrong.

Charles.

rbair
Offline
Joined: 2003-07-08
Points: 0

Charles,

> I think you would need Strong typing before the
> current
> API would be applicable for Domain Models, which
> would
> mean a substantial redesign. Types are tke key
> abstraction
> in Domain models.

Why? Could you please explain why strong typing would be necessary for the api to be useful? Do you have a use case?

> Even then you are still left with the problem issue
> which is persistence. Serializing beans always run
> into version control problems - so you still have to
> map the beans to
> a relational database.

Red Herring! *Everybody* has to deal with this. JDNC sits on top of such persistence mechanisms, it doesn't handle them.

Rich

charles.armstrong
Offline
Joined: 2006-02-17
Points: 0

Rich,

Use cases: Yes - look at Karstens Binding papers and see
how he uses types.

Persistence - please read earlier posts in this thread
re: RAD developers (the 10 million that JDNC was designed
to help move onto the Java platform)

Rowsets: Please read other threads. The current API is
definitely Rowset Orientated - maps well to Rowsets but
not to beans (Amy herself stresses this in other threads)
eg Lack of typing, no property ordering etc etc

Charles.

rbair
Offline
Joined: 2003-07-08
Points: 0

Hey Charles,

No, JDNC is *NOT* designed primarily around RowSets. I have used a JDNCish API for wrapping beans for a very long time, and it works very well. Why would the API not work with beans? Its a simple matter, isn't it? Use reflection to call get/set methods on objects.

Look, if you are using beans as your primary data model (as opposed to say, RowSet), then you interact with those beans primarily in 4 places.

First, the persistence layer. Persistence is orthogonal to data binding. Whether you use JDO, Hibernate, pure SQL, serialization, SOAP, or any other back end technology is irrelevant. One of the JDNC design goals is to be data store agnostic. If there are points in the API that are not abstract enough, please, by all means, point them out.

Second, in gui controls. Clearly a binding between a JTextField and a bean is pretty simple -- call the getXXX method on the bean to populate the JTextField and the setXXX method to save the JTextField data back to the bean. Since we have reflection, we can easily wrap the bean up in the same DataModel and use the same semantics that we use with a RowSet.

Third, Renderers. A renderer may want to do some fancy stuff with the bean and call one of the beans methods. Fine. Just call "getJavaBean" on the DataModel and viola, you have your bean and can do with it as you please.

Fourth, event handling. This would be essentially the same situation as with the Renderers. Get your bean from the DataModel and do what you want with it.

What's left out? How is JDNC being restrictive or incapable? What do you need to change, and why? What is your use case? Being obtuse isn't going to help your cause, specifics please.

Richard

charles.armstrong
Offline
Joined: 2006-02-17
Points: 0

> Use reflection to call get/set methods on objects.

I rest my case.

If you think thats an appropriate way to build an
enterprise system with 100s of Domain Types then I am
afraid we are never going to agree.

Why is it too abstract for you to see that persisting
Rowsets is trivial compared to Domain Objects. I
recommend any Rowset tutorial and any book on
Domain Objects - Craig Larman 'Applying UML and patterns'
is an excellent introduction, with a whole chapter
on Persistence issues. Or look at any book on Object
Relational mapping to see all the issues. In a sentence
PERSISTENCE EFFORT IS PROPORTIONAL TO THE STRUCTURAL
DISSIMILARITY BETWEEN THE CLIENT SIDE STATE REPRESENTATION
AND THE BACK END DATASTORE.

Rowsets map trivially to Databases - Domain Objects do not. Persistence is NOT an orthogonal issue because the
stated goal of JDNC is to make development easier for
Visual Basic types and move them onto the Java platform -
so you have to have a programming model where
persistence is trivial - otherwise you get no
net productivity gain.

I find it astonishing that you deny that the current
API is TableModel/Rowset Orientated when you participated
in this thread:

http://javadesktop.org/forums/thread.jspa?threadID=4613

Yes - I am sure you could write an OO system where
everything extends Object or String - and do all method
calls by reflection - but your code would be
horrendous.

Maybe you should post your reflection code - and then
compare it to the typed examples Karsten gives in
the binding paper at:

http://www.jgoodies.com/articles/

I hope its obvious business logic is far easier with
types. If not obvious any gentle OO introduction
will help.

At the GUI level you need typed info to configure your
display (column ordering etc) - non-displayable
properties etc. Karstens binding paper shows how his
types interact with the GUI.

Are you suggesting the GUI should magically reflect its
way through an entire domain model? In which case you
are into Naked Object land (www.nakedobjects.org) - and
even they have a strongly typed approach.

Charles.

rbair
Offline
Joined: 2003-07-08
Points: 0

> > Use reflection to call get/set methods on objects.
>
> I rest my case.
>
> If you think thats an appropriate way to build an
> enterprise system with 100s of Domain Types then I
> am
> afraid we are never going to agree.

You are quite correct, we never will agree. Reflection is a very powerful tool, and one that I have used in Java for years. Its very simple conceptually. Using reflection is appropriate, FUD aside.

> Why is it too abstract for you to see that
> persisting
> Rowsets is trivial compared to Domain Objects.

What makes you think that's my opinion? I've used JDO, home rolled solutions, object relational databases, serialization, and SQL. For some reason you think it is proper to insult your opponent. Sorry pal, but your tactics do you no credit.

Mapping between objects and relational databases is a problem for everyone who has to do it. What makes you think JDNC needs to address the problem? We shouldn't deal with persistence at all, other than to indicate to an adapter that something needs to be saved and let the adapter do the work.

> I recommend any Rowset tutorial and any book on
> Domain Objects - Craig Larman 'Applying UML and
> patterns'
> is an excellent introduction, with a whole chapter
> on Persistence issues. Or look at any book on Object
> Relational mapping to see all the issues. In a
> sentence
> PERSISTENCE EFFORT IS PROPORTIONAL TO THE STRUCTURAL
> DISSIMILARITY BETWEEN THE CLIENT SIDE STATE
> REPRESENTATION
> AND THE BACK END DATASTORE.
>

Hmmm, casting more aspersions on my intellect and experience.

> Rowsets map trivially to Databases - Domain Objects
> do not. Persistence is NOT an orthogonal issue
> because the
> stated goal of JDNC is to make development easier
> for
> Visual Basic types and move them onto the Java
> platform -
> so you have to have a programming model where
> persistence is trivial - otherwise you get no
> net productivity gain.

Two words: not true. If VB like developers want simple, they can use RowSets with the API. If somebody wants to use Hibernate or JDO instead, fine the API works with that two. Persistence is orthogonal.

> I find it astonishing that you deny that the current
> API is TableModel/Rowset Orientated when you
> participated
> in this thread:
>
> http://javadesktop.org/forums/thread.jspa?threadID=461
> 3

You seem to not understand that I am pushing to make sure that RowSet is properly supported. RowSet's may have been in Aim, Mark, and Ramish's minds as they developed the API, but they never implemented anything in relation it. That's obvious, if you've read the code.

> Yes - I am sure you could write an OO system where
> everything extends Object or String - and do all
> method
> calls by reflection - but your code would be
> horrendous.

Straw man.

> Maybe you should post your reflection code - and
> then
> compare it to the typed examples Karsten gives in
> the binding paper at:
>
> http://www.jgoodies.com/articles/

My code is freely posted for all to see. Look at the JGUI code in the XOM project on sourceforge. Check out the BeanSource. You will find a couple of methods that use reflection. Hmmm, in truth reflection makes up a very, very small portion of the code.

> I hope its obvious business logic is far easier with
> types. If not obvious any gentle OO introduction
> will help.

Ah, more personal attacks. Keep 'em coming.

Out of deference to the rest of the JDNC community who is doubtless more interested in getting something done than seeing two guys argue, I'm not responding to Charles anymore on this thread, inasmuch as he seems convinced of his own superiority and my obvious lack of experience and intelligence.

Richard

charles.armstrong
Offline
Joined: 2006-02-17
Points: 0

Rich,

Wrong.

I found the earlier posts especially from Scott incredibly
insightful, and hope I responded to them with respect.

It was only your posts that I found bone headed, and you
clearly hadn't bothered to read the thread.

I have seen you bludgeon down Scotts intelligent arguments in other thread with dumb ones - and didn't intend to let this thread suffer the same fate.

I am not saying YOU lack intelligence, just that your comments do.

Anyway - let the code talk. We'll see whether anyone succeed to write their business logic using reflection.
If so I'll buy you a beer and apologise.

rgds,
Charles.

rbair
Offline
Joined: 2003-07-08
Points: 0

Ok, I guess I can respond to this one :) To be honest, I thought you were being rude to Scott and I wanted to show my support. Oh, the vagaries of communicating by the written language alone.

> It was only your posts that I found bone headed, and you
clearly hadn't bothered to read the thread.

Well, I had read the thread but thought your posts were the only bone headed ones here, in addition to being rude :). We are undoubtedly at opposite positions on this one and everybody else is in the middle somewhere. That's the powerful bit about the open source development model -- the community decides and if the community is big enough then the best ideas usually win out in the end. Even if they were't mine ;).

>I am not saying YOU lack intelligence, just that your comments do.

As my dad would say, its 'better than a kick in the head'.

Sorry again for any hard feelings. As Jeanette points out I think we need to be speaking some kind of common language before jumping into this. All this talk of reflection being a horrible idea and then supporting Karstens binding (which uses reflection) suggests we aren't speaking the same language. In my "rude" post I was really just trying to get a clear explanation of your position because from the thread it didn't make sense to me. I also hate complexity for complexity sake, and having seen an architecture like JNDC in action -- I just haven't seen the weaknesses that you are suggesting.

As for the whole JDNC/RowSet thing, I have to respectfully disagree. I don't see the difference between a collection of beans and a collection of rows. Fundamentally, a collection of beans can be described in a tabular format the same as relational data. The difference comes (correct me if I'm wrong) when you attempt to describe relationships between entities (nested entities, or the entities listed in another table).

Which brings me back to a previous post. We interact with our data through 1) bound gui components, 2) event handlers, 3) renderers. What I can't seem to understand is why a tabular view of objects won't work with #1, and why being able to extract the object won't work with #2 and #3. Also, I don't see how you can have one unified API for both RowSets and Objects that doesn't use the tabular data model as the base abstraction. I don't think wrapping rows of a RowSet in an object is an option -- but maybe you can.

Respectfully,
Richard

scottr
Offline
Joined: 2004-09-05
Points: 0

Hi Charles and Rich,

FWIW, I haven't taken any of your comments to be rude and demeaning (to me, at least ;)). I've enjoyed the exchange of ideas and viewpoints on this topic.

My original point was that it should be possible to integrate these different approaches into JDNC, which I see as being useable for RAD jdbc/RowSet data approaches and also more complex object domain models.

I don't sweat the use of reflection too much for form binding, mainly because I see that as involving trivial operations (get/set the data, possibly rendering it differently, reacting to value changes). But when that functionality crosses over to invoking business logic, then I prefer to stick to custom-coded actions with type-safe references to the underlying data.

Hence my thought that JDNC could supply most of the boilerplate binding/loading logic and leave business actions up to the developer, and form beautification to the gui developer. Even for java beans.

But I do take the point that when you have a rich domain model where business logic is likely to be called frequently, then such an approach starts to fall down.

Scott

Kleopatra

jdnc-interest@javadesktop.org wrote:
>
> I don't agree that the two approaches have similar goals.
>
> In JDNC you have a Rowset, so persistence is trivial. This
> works well for simple projects.
>
> In JGoodies you have a rich client Object Model, but you
> then have to deal with all the issues of mapping these
> client side Objects to a relational database. So you have
> to have lots of SQL etc in your property change listeners.
> So this isn't for the faint hearted.
>

Hmm, not sure if I understand you correctly (or at all :-).

Though one important aspect of JGoodies Binding is the out-of-the-box
support of rich object models, it's more general than that - a
ValueModel can be used anywhere. And meaningful collections of
ValueModels could be build in analogy to BeanAdapter/PresentationModel.

In the experimental code I posted in the other thread, I wrap f.i.
individual table cells with them and then have all the Goodies binding
to swing components for free. Similarly, I could build a chain between a
Rowset and swing component (at least that's what I expect naively)

Greetings
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

charles.armstrong
Offline
Joined: 2006-02-17
Points: 0

Jeanette,

>a ValueModel can be used anywhere. And meaningful >collections of
>ValueModels could be build in analogy to >BeanAdapter/PresentationModel.

Yes you could use a Value Model - but for the developer
who wants to map a JTable to his data using an
XML descriptor value models would seem like overkill. This
type of developer wants as simple and obvious a relationship between the GUI and back end storage
as possible. For this type of developer/project a
Rowset is an excellent thing to bind to.

>Similarly, I could build a chain between a
>Rowset and swing component (at least that's what I expect >naively)

If you look at what a fine grained client side Domain
Object model looks like it will have lots of derived
fields, methods acting on encapsulated data,
associations, relations, aggregations and WORST of
all inheritance. So any mapping/chaining to Rowsets
would certainly not be trivial.

So my central point is a Domain Object model is a very
powerful thing, but once you add that to the pie,
the RAD developer that JDNC is targeted at is
going to get indigestion.

I hope I have explained myself properly - I tend to
jump over steps in my chain of thought.

Charles.

Amy Fowler

jdnc-interest@javadesktop.org wrote:

> Hi Guys,
>
> Have you seen this project https://binding.dev.java.net/ also underway on JavaDesktop? It seems to overlap a lot of what JDNC covers, at least as far as the binding part goes.

JDNC's binding framework had been developed before Karsten made his
binding framework available, but we fully intend to explore the option to
move to using the jgoodies binding framework in the swing-extensions layer of JDNC.
We'd likely add higher-level API in JDNC's highlevel components to make
binding as simple as a method call, for those who don't care about the
fancy OO details.

> It would be nice if this stuff could make it into JDNC, rather than having so many different incompatible projects trying to achieve the same purpose.

Completely agree.

Aim

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

charles.armstrong
Offline
Joined: 2006-02-17
Points: 0

I don't agree that the two approaches have similar goals.

In JDNC you have a Rowset, so persistence is trivial. This
works well for simple projects.

In JGoodies you have a rich client Object Model, but you
then have to deal with all the issues of mapping these
client side Objects to a relational database. So you have
to have lots of SQL etc in your property change listeners.
So this isn't for the faint hearted.

.net supports both approaches to development, so it would
be good if Java did.

Charles.

scottr
Offline
Joined: 2004-09-05
Points: 0

> I don't agree that the two approaches have similar
> goals.
>
> In JDNC you have a Rowset, so persistence is trivial.
> This
> works well for simple projects.
>
> In JGoodies you have a rich client Object Model, but
> you
> then have to deal with all the issues of mapping
> these
> client side Objects to a relational database. So you
> have
> to have lots of SQL etc in your property change
> listeners.
> So this isn't for the faint hearted.
>
> .net supports both approaches to development, so it
> would
> be good if Java did.
>
> Charles.

I agree that both these approaches (and others) should be supported.

I think that what Karsten is doing is a subset of what JDNC is trying to achieve. My comment was just merely that having a half dozen projects all working towards the goal of transparent data binding, but in incompatible ways, will only achieve fragmentation.

Scott

charles.armstrong
Offline
Joined: 2006-02-17
Points: 0

>I agree that both these approaches (and others) should be >supported.

>I think that what Karsten is doing is a subset of what JDNC > is trying to achieve. My comment was just merely that
> having a half dozen projects all working towards the goal > of transparent data binding, but in incompatible ways,will > only achieve fragmentation.

> Scott

Agree with all that although not 100% sure what you mean by subset.

As I understand the goal of JDNC is
"Ease of development for data-intensive applications in
the J2EE space" (i.e. its end to end and persistence
considerations are part of the deal, but the target
apps are data-intensive and relatively simple)

and the goal of JGoodies is 'Binding Domain Objects to
GUI components'. This is useful when you need to attach
lots of additional methods to your domain Objects
e.g. calculatePension() etc. However I haven't seen
consideration given in JGoodies to ease of persistence;
I think that aspect is being left open giving people
the option of SQL, O-R mapping tool or Object DB etc.

So I guess JGoodies is a subset in the sense its less
end to end - but JDNC is a subset in terms of application
complexity - prizes to anyone that can draw the
Venn diagram!!

Charles.

scottr
Offline
Joined: 2004-09-05
Points: 0

>
> Agree with all that although not 100% sure what you
> mean by subset.
>
Specifically I meant that JGoodies Data Binding framework is more focussed on the actual binding mechanism between the undelying data, and the GUI components that render (and transform) it. JDNC also has a binding framwork, but as part of a larger API to handle end-to-end persistence.

> As I understand the goal of JDNC is
> "Ease of development for data-intensive applications
> in
> the J2EE space" (i.e. its end to end and persistence
>
> considerations are part of the deal, but the target
> apps are data-intensive and relatively simple)
>
> and the goal of JGoodies is 'Binding Domain Objects
> to
> GUI components'. This is useful when you need to
> attach
> lots of additional methods to your domain Objects
> e.g. calculatePension() etc. However I haven't seen
> consideration given in JGoodies to ease of
> persistence;
> I think that aspect is being left open giving people
> the option of SQL, O-R mapping tool or Object DB
> etc.
>
Yes, this is true, however, a lot of discussion in other threads has centred around how to handle complex domain objects in JDNC, as well as simple jdbc-oriented data structures (ie. RowSet).

Ultimately, though, the core goal of both projects is to have an API that allows easy development of data forms that handle most commonly recurring binding, navigational and transactional logic. And I do not think there is such a world of difference between object domain models and jdbc data structures that the two could not be handled by the same API. I would not like to have to switch libraries and coding styles trying to code to both object models and jdbc data. And I expect that in real world applications you will get mixes of each.

Scott

charles.armstrong
Offline
Joined: 2006-02-17
Points: 0

Scott,

>And I do not think there is such a world of difference >between object domain models and jdbc data structures that >the two could not be handled by the same API

I think that is our one point of disagreement, but I think
its at the heart of the issue.

I was writing a reply to Jeannette saying why I
think Domain Object Models are a totally different beast,
when your post appeared, so won't duplicate it. Hopefully
it'll still be in the comment above this one when I
press post :)

Charles.

scottr
Offline
Joined: 2004-09-05
Points: 0

> >And I do not think there is such a world of
> difference >between object domain models and jdbc
> data structures that >the two could not be handled by
> the same API
>
> I think that is our one point of disagreement, but I
> think
> its at the heart of the issue.
>

I think there's a difference between rich domain models and thin domain models. The former tends to have lots of business logic built into the objects, whereas the latter uses objects as data structures only. To this end, thin domain models often serve that purpose better than raw jdbc data, particularly when dealing with master-detail models (think of the pain of trying to keep header and detail RowSets in synch).

I wouldn't use a rich domain model in a JDNC binding framework unless all processes were running in the same JVM. I would be cautious about calling methods on those objects in a client-server network, where those business methods could incur RMI calls.

Personally I prefer thin domain models with separate business handlers, but thats my preference. Others prefer rich domain models and others prefer working with jdbc data structures. It would be nice to see an API that allows all three approaches to be used transparently.

Scott

charles.armstrong
Offline
Joined: 2006-02-17
Points: 0

Scott,

Ever considered politics?

I think if you said 'Domain Model' to most developers they
would think of UML diagrams will all the goodies (ie.
all four types of arrows) and methods.

Your 'thin Domain Model' concept is a great political
device, but I think most people would call those Data
Objects. Unifying Data Objects and Rowsets is quite
fesable - however once you do 'Domain Orientated
Development' that rather applies rich Domain Models.
I think then any attempt at unification will fail due
to the Object/Relational disconnect.

Your remote calls point is a very interesting one. The
solution lies in Event Driven Architecture (see some
of the work in the Hibernate space - and I've also done
a lot of work in that area myself).

Charles.

rbair
Offline
Joined: 2003-07-08
Points: 0

Check out this thread for more on this discussion:

http://www.javadesktop.org/forums/thread.jspa?threadID=4763

rameshgupta
Offline
Joined: 2004-06-04
Points: 0