Originally posted by Gavin Tranter:
I need to objects, one that represents the lazy method and is just the parent and one that is the parent with its child objects (perferable as a list?)
In Hibernate, lazy loading of persistent relationships and collections is facilitated by proxies. For example, let's say you have a LooneyBin object that has a collection of Nutter objects that is lazily loaded. If you call looneyBin.getNutters(), Hibernate will only load the ID and version number of the Nutter objects, thus saving all the work of loading individual objects until later. You think you have all the related Nutter objects, but what you really have is a collection of proxies. The thinking is that if you have a collection of a few hundred items, chances are good that you'll only work with a few of them, so why go through the effort of instantiating all the objects. This can be a huge performance gain in certain situations.
Originally posted by Gavin Tranter:
However, I do wish to ORM this, but I just dont understand how to model the objects, and have never been able to find a decent document on the why and wherefore of the modeling, they all just seem to dive rigth in and just go a head and map things.
I am not sure about these proxies... I am getting the idea that I might like to investigate the design patterns ORM and/or Hibernate use as the proxy objects seem to ring a bell as a design pattern.
What I am getting from this thread is: I probable model the Author with a Book collection, and that the book collection dosnt get filled if I just as my ORM layer for an Author.
Originally posted by Mark Spritzler:
Gavin, at this point, I don't recommend you needing to completely understand the proxies, when there are proxies in your collection, or that, since we need to concentrate more on OO design, and that you have only one object model, and not different models for different use cases.
Then we can move onto ORM, and how you map and write queries, and how it results in objects being filled with data.
The books you read on ORM tools won't talk about how you should design your objects, because that is an OO Design issue and not an ORM issue. It will talk to you about how you can take any OO model and map it to any Database model. It will talk about how the objects get filled with data, or not based on queries, mappings, and fetching strategies.
Mark
If you are not laughing at yourself, then you just didn't get the joke.
Originally posted by Arun Kumarr:
-- Was that to Gavin Tranter, Mark.![]()
[ April 15, 2007: Message edited by: Arun Kumarr ]
Originally posted by Mark Spritzler:
we need to concentrate more on OO design, ...
Then we can move onto ORM, and how you map and write queries, and how it results in objects being filled with data.
Originally posted by Mark Spritzler:
I'm sorry, I don't get it, there is only one Gavin in this thread.
Mark
Originally posted by Gavin Tranter:
I think it might come down to one simple question, of object modelling, and do I put a collection/single instance of the child object, in the parent, and my reluctance to have a null reference or 3 hanging around in objects.
Originally posted by Gavin Tranter:
Obviously you are never 100% decoupled from your DB, or persistence layer, as you are manipulating what you wish to persist, so you are always dependent on your data.
�
So I have a DB, and I have an Object per table, that exactly matches the table field to field.
Originally posted by Mark Spritzler:
So you only have the Author data in the Author object, for that query.
...
So in this query the Collection of books is loaded with objects.
So rather than being decoupled you have chosen to have a 100% coupled object model by synchronizing it with the DB Schema. In most cases the DB Schema is more likely to change than the underlying RDBMS engine.
- How are you going to tell the difference between a lazy-fetched author and a eager fetched author with no books?
- Are you assuming some kind of mechanism to ensure that any one author object only exists once in the entire application work space?
(I'm assuming a hand coded DAO rather than an ORM backed one).
Originally posted by Gavin Tranter:
Well I dont see how you can ever decouple yourself from your data
So I would add ORM later
Originally posted by Mark Spritzler:
"How are you going to tell the difference between a lazy-fetched author and a eager fetched author with no books?"
Huh? Why does that matter? You shouldn't have this issue, or there is a design flaw.
Originally posted by Gavin Tranter:
1) Ah yeah I read that and strangle had used variations of two of the described techniques.
2)hmmmmm, yes I see that, I would tend to take the preformance hit in teh DB and normalise the "large" table to be many smaller table, I sometimes find that if i have such a large table, I have missed a "repeating" data group that should have been normalised anyway.
OK, so what happens if you have to map to a legacy database that has the tables already defined and data already in it, that is really when #2 comes into play.
If you think about it this way, does Data Modelling follow good OO practices? No, it doesn't care about OO, it is not OO. So then you can say, well if I create Objects one to one to the tables that aren't OO, then does that mean that my object model will be OO.
In addition to #2, there are times when you want two objects to represent a table, even when the table doesn't have lots of fields. This is where @Embeddable objects come into play. A good example is a Currency object that has CurrencyType and amount. But in the database you just store amount in the table. Or things like that.
So it takes a day for light to pass through this glass? So this was yesterday's tiny ad?
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
|