• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

ORM Mapping, Best practices?

 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
Sorry if this is a repeated question, and i get my terminology a little wrong.

I have a several one to many mapping in my DB, and even some tables that have several parents.

My question is when modeling these in ORM terms, for the parent calls do i provide a bean with a collection for the child records AND a bean just for the parent class by its self.

As an example, I might want to add a parent but have no child objects to add, (if the cardinality of the one to many is 0 or more).

Of course you might also want to have a child "show" its parents data, say you had a book, and an author, you might when dispalying the book, need to display the author detail, and when displaying the auther display a list of their works, but equally, you might just want to display auther as stand alone.

Perhaps I provide an "object" for each of these situation and have the DAO return the correct one?

Sorry its a bit vague, as I have not chossen which ORM tool to use.

G
[ April 11, 2007: Message edited by: Gavin Tranter ]
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, here is the thing. When building your object model, the Java objects, ORM is there to make it so you should do this in an OO fashion, not even thinking about how the database is set up.

When you have related objects, you want to allow the default lazy fetching strategy, so if you get an Author you just get the Author single object with data filled in, and you do not get any Book objects with data. Then if you have a use case that needs Authors and all the Books, then in the Query that you write to get that data you set the fetching to be eager so that you can get the data in either 1 or 2 queries, instead of N+1.
N+1 meaning 1 Query for the Author, and a query for each and every book that the author has written. If the Author wrote 10 books then N+1=11 different queries.

Mark
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, if i am understanding correctly, 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?)

This is the part of ORM I have an issue with, perhaps it is down to how i design databases

G
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, not at all. Forget about the database and lazy or eager. This is all about OO design here, get that how you want it.

Then after that you can map your objects to the database tables.

But basically you have this an Author object that has a collection of Book objects. The Book object can have a reference to its Author object

The lazy/eager comes in later when you query. If you need to get all the books for an author, you tell the query to eager load the Books collection. Otherwise lazy load the book collection, which means the first query will not put in data into the Book collection. Only when you try to access the Book collection will Hibernate then go back a get the book data. I suggest going to searching for tutorials or articles that demonstrate the Persistence Context and Fetching Strategies.

There are three parts to Hibernate really.

1) Mapping
2) Querying
3) Persistence Context/Transactions, and state of objects.

You need to understand each part.

Mark
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?)


No you don't need two objects. Hibernate for example when configured for lazy loading will transparently/invisibly provide the parent which a proxy collection that will act like the collection of children that the parent is expecting but in fact handles all the lazy loading logic for the parent.


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.

Proxy Visitor Pattern
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think this is where I have problems, the modeling side of things.

Right now I have no ORM, I have some DAO objects which will return an Author, and given an AuthorID return all that Authors Books.

The Author object, currently knows nothing about Books. While a Book Object knows an AuthorID.

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.
But they never seem to say, ok, sometimes your just interested in the Author object and you dont want the Books, so you just model you object in this way, or that x y and z are your options.

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.

I am not sure about these proxies... I am getting the idea that I might like to investigate the deisgn patterns ORM and/or Hibernate use as the proxy objects seem to ring a bell as a design pattern.

G
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


Agile Data: Introduction to Object-Orientation and the UML
Agile Data: Object Relational Impedance Mismatch
Agile Data: Mapping Objects to Relational Databases: O/R Mapping In Detail

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.


In certain situations you need to be aware that you may be dealing with a proxy rather than 'the real thing' - other than that proxies are invisible. Hibernate generates the necessary bytecode for you using CGLIB (starting in 3.2 it can also use Javassist).

Initially you may have trouble trusting this automatically generated code - however this is one of the cases where code generation is a good thing. Trying Hibernate out hands on is probably the easiest way to deal with these 'trust issues'.

Many of the patterns used inside of Hibernate are actually well documented in Patterns of Enterprise Application Architecture (PEAA) amazon US. For example, the Hibernate Session is a Unit of Work which internally uses Identity Maps. Ultimately the use of an ORM is supposed to enable you to focus on creating a Domain Model suitable for your business domain.

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.


That depends on how you configure your ORM. You may know that when you load the author that you will need to all the author�s books anyway in which case you can configure the ORM for an eager load. However the ORM gives you the option of a Lazy Load which is useful if you only need a few of the author�s books.
[ April 13, 2007: Message edited by: Peer Reynders ]
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Arun Kumarr
Ranch Hand
Posts: 661
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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


-- Was that to Gavin Tranter, Mark.
[ April 15, 2007: Message edited by: Arun Kumarr ]
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Arun Kumarr:


-- Was that to Gavin Tranter, Mark.

[ April 15, 2007: Message edited by: Arun Kumarr ]


I'm sorry, I don't get it, there is only one Gavin in this thread.

Mark
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


Mark is of course correct.

You seemed to however display a curiosity towards what makes ORM "tick", you may even feel the need to know how it works before you can trust it, so I offered the above references. However PoEAA is not a book to learn OOD from.

You haven't mentioned however whether you are constrained by an existing DB Schema or whether you have the freedom to define your own. If you aren't constrained by an existing DB Schema it makes sense to do your domain objects first.

If you are still skeptical that 'Persistence Ignorant' (PI) Domain Objects can work then have a look at this sample chapter:
Chapter 6: Preparing For Infrastructure (PDF) of Applying Domain Driven Design and Patterns amazon US. You don�t have to understand it all, but it gives you an idea of some of the options that persistence frameworks can exercise and to what degree these options interfere with the Domain Objects being PI.

While the book identifies itself as an .NET/C# book, the existence of Hibernate in both the .NET and Java space makes a large portion of the book equally applicable to the Java platform (Domain-Driven Design is platform independent and many of the patterns discussed apply to multiple platforms).
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Spritzler:


I'm sorry, I don't get it, there is only one Gavin in this thread.

Mark


Dont get it either *shrugs*
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have to say at this point you have all been great, I am sorry if I seem confused on this subject, it is because I am.
Yes I do wish to know how ORM works, I like to know how the technologies that I work with, work. Hell I even had to figure out how to command line compile C#, not fun (Cos we didn’t have VS at the time). But I believe you should understand as much as you can about what you are using, it might not stop you using it wrongly, but at least you will not what you are doing and why.

I will have a read of some of the links and get back to you.

Thanks.


ok so some background.
Some years ago before hibernate existed (or probably before this time) around about 2000, I worked for a company and the TA decided to have a Data model which you accessed though Objects that had no idea of the data layer, we had a layer we called dbAPI that accessed the DB and got the objects. So I really believe in the ORM ideal if you will. 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.

The state I am in is that I have a schema, its mine, so it takes some of the ideas from the (above) experience (some of which I am thinking are over kill for this project), not saying its perfect for its domain, but, I think it will work.
So I have a DB, and I have an Object per table, that exactly matches the table field to field.

Then I have a DAO per object that will (currently) retrieve a list of that Object/Set of rows. (Currently an interface with a JDBC imp, I am hoping that I can later create a ORM version and just switch imps, or that’s the theory anyway).

I have use cases where I will want to get just the Object, and where I want to get Object and child Objects, and where I want to get the children of a given object (3 use cases).
Now its a web based app, so the chances are that the child objects will be hidden until a user requests more info, I have taken the stance that why fetch what I wont need, fetch it when I need it. So for 90% of the time the first and 3rd use cases will be used.

I have not even considered ORM as persistence at this point, it was a "next step" thing, but you have brought to light I having an issue modelling the use cases. I understand that the DAO is there to enable DB interaction, so I can put all my queries and inserts in there.

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.

Thanks
G
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


If you keep the author separate from the book collection you aren't really creating a Domain Model and especially in the case of a web application you'll just end up creating a bunch of Transaction Scripts. For simple systems there is nothing wrong with transaction scripts (most SLSBs are just that). However ORMs exists to support a Domain Model which usually is the result of the object modeling effort. If you are working with a system that can be sustained on transaction scripts then DAOs might be overkill and more simple constructs like a Table Module or Active Records might be more appropriate. Your current approach is more in line with a Table Data Gateway.

PS: This doesn't apply in this case - but whenever you find yourself struggling with a NULL field consider Introduce Null Object (pdf).

Robert C. Martin: Principles of OOD
[ April 16, 2007: Message edited by: Peer Reynders ]
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"So I have a DB, and I have an Object per table, that exactly matches the table field to field."


ORM, would actually having more objects than tables, so that the Object model is as OO as possible.

Now in regards to you 1 to many and object modelling. You are completely correct in your thinking of only getting the data you need when you need it. But it shouldn't affect the Object model. What it affects is you use cases and queries.

One concept you might want to read about is lazy/eager fetching and fetching strategies.

So you can have an Author object have a collection of Books, but in the first Use Case you lazy load the collection, meaning there is nothing in the Collection. So you only have the Author data in the Author object, for that query. Then in say another DAO method you have a query that will eager load the Books collection when you get the Author. So in this query the Collection of books is loaded with objects.

Mark
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

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.

Table Gateway style DAOs are nice and easy to set up - but DAOs don't really earn their keep until they deal with Aggregates (a cluster of associated domain entities). However the more complicated the aggregate, the more complex the DAO, which can quickly get out of hand - unless you have the right tool to help you (ORM - which also handles eager and lazy loading for you).


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.


- 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).
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


Well I dont see how you can ever decouple yourself from your data, I do agree that chances are your Schema will change more often then your actual RDBMS.
Also from what I could tell at least one of the (Agile) links yesterday seemed to be suggesting that your object model is closely coupled to your DB model, and in actual fact drives your DB model (although I this is the reverse to how i approach things normally).


- 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).


Currently yes hand crafted DAO, I started out from the point of view that I didnt want to really write all that web code stuff so I chose a framework (Spring, I quite like some of its principles and I have heard good things from friends), I also decided that ORM would be nice too, but learning ORM at the same time as (hacking) a Spring based web app together seemed like a bad Idea, and I personaly felt that I want to spead more time with ORM as it would suffer from just trying to hack something together to get up and running, so I would add add ORM later, it just seemed a case of using a different set of DAO.
Now I am realising that there are a lot of data access issues thrown up by using DAO, some are the same if you are using ORM or not, and some are reduced by using ORM so by removing ORM to a later stage I have kinda shot myself in the foot.

G
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gavin Tranter:
Well I dont see how you can ever decouple yourself from your data


The idea behind an integration tier (data access layer if your resource is a DB) is to decouple you from the structures that the underlying resource is using to manage the data. Yes, ideally the Domain Model (which models your domain (business) with data and behavior, rather than just focusing on the data) should be driving the changes in the DB schema - not the other way around - however quite often the DB schema exists before the Domain model is created. So, at least initially, you would be forced to hide the complexity of the mapping within the integration tier (DAOs, ORM, etc.). In many cases you are locked into the schema because of other legacy systems that are directly dependent on that schema. However even Database Refactoring is possible - so eventually you could eliminate any accidental complexity letting you focus on essential complexity.

So I would add ORM later

You can still develop your domain (object) model independent of everything using TDD. You could even develop many aspects of your presentation without the persistence aspect by programmatically loading a default set of instances of your domain objects into memory - you can even check (test) the changes that are being made - you just won't be able to persist those changes.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"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. Your code for your use case calls one or the other DAO method query, and the one that doesn't need books, calls the lazy fetched one, and never calls getBooks nor needs to look through the book collection.

The Use case that needs an eager fetched book calls the DAO method that eager fetches, and that use case loops through the Collection. If it has no books then it has nothing to loop through, really has no affect on your code, nor should it.

If it has an affect on your code, then I would say that is a design flaw, rather than an ORM issue.

The case of defaulting everything to lazy, and make your queries for use case determine when to eager fetch is the way that you will get the best performance of your queries, bringing back only the data you need, and decoupling your mapping from your use cases.

Your application shouldn't need to care whether it is a lazy-loaded Author or one that has no books. It just has an Author object that has a Books collection. The think that a developer should care about is if the developer is writing code that is trying to loop through a lazy-loaded collection outside the scope of a persistence context (Session or EntityManager Unit of work).

Mark
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


Indeed. However use cases usually do not concern themselves with implementation details like lazy-loading � as far as the use case is concerned the author always travels with her books. Meanwhile a method that is handed an author has no way telling that it has been handed a (lazy-fetched) dud � it will always act like its an author with no (published?) books. Testing should catch that, sure �
That makes Hibernate proxy objects so useful. It�s one less thing you have to track in your head because the 'whole' can always get a hold of its 'parts'. Your performance may suffer because of incorrect (eager/lazy-load) configuration but the parts can always be obtained.

As to the identity issue: Usually Mock DOAs (or Repositories) will corral the in-memory instances in some kind of collection - chances are that if you call the get method twice that you will get the same object. However in a DB backed system (without ORM) a DAO (or Repository) without identity map(s) will create a new object with each get. This is especially true if the object is retrieved with different find methods or criteria. Both copies could be updated differently leading to indeterminate results when you try to persist them.
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guys I have to say you have been great, a lot of this is kinda going over my head.
However, its made me realise, a couple of things. That perhaps I model data in teh "wrong" way, and that my development style is also perhaps not the best for web/apps data modeling.

I think we have cleared up my major missunderstanding, of what to do about child "objects" and that is you decide on an object by object bases, and opened up a can of other stuff for me to get my head around that I hadnt considered before.

For example, the Author/Books example, you would include a collection in the Auther, and it gets filled when need.
For the example of a one-to-one mapping, say they type of book (Hardback, paperback etc) you would probable always load this data as you would rather see the book type rather then a code.

I worked on the data model first, and that is driving my application. Why? seemed logical as I was modeling a paper (spreadsheet) system, and teh behaviours are just add/amend and delete, i never considered modeling from the domain side of things.

I still dont understand why the behavor is modeled in conjection with the DB, perhaps because of the simplicity of the data I am modeling. As all I will have is add amends deletes, even the versioning i have built into teh model will be hidden in the gets and sets.
Which leads to, I dont see how I would end up with more objects in my "model" code other then those of the tables I am representing, I mean I know I will have DAO and other domain objects to do work etc, but i dont think you ment those. I have an Author table, I will have an Author object, there is a one to one mapping.

This is the limit of learning over the web, for me, I need to sit down someone, and see worked examples, and become that six your old asking "why" and "what if"

G

[ April 18, 2007: Message edited by: Gavin Tranter ]
[ April 18, 2007: Message edited by: Gavin Tranter ]
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The more objects than database tables comes in many forms

1. Databases don't have inheritence, so you could have an inheritence Object model with say BillingDetails object that has two subclasses CreditCard and BankAccount. However, in the database you might have only one table calling BILLING_DETAIL that has a billing_type field that is a string that tells us if it is a creditcard or a bank account.

2. Your database table has way too many fields, and you want to make more than one object in your object model to cover all the fields. One Java object with say a hundred attributes to me would be a poorly designed OO Object.

Just two examples.

Mark
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Mark
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.


Ah yeah, good point, I usual have created the tables whilst thinking of the objects, so my tables as a rule are the properties of my objects So I would usual say they are fairly OO designed Objects/Tables I do tend to see the DB as a store for my objects.
I have never had to map to a legacy DB. This perhaps explains my confusing on the Object model side of mapping having more objects then tables as I have never had that experience.

Well I dont know about @Embeddable , would I use that in the following example:
Book has a genre, there is a genre table, and the Book has a frogin key to it. (sorry I am still thinking in terms of data first :S)
So in my book object would I make genre and @Embeddable? and would I get all the fields that come along with Genre? (I am assuming a book only has 1 genre )
I am thinking of data is mapped 1 to 1 in the tables, like thing x has status y, and you would probably want the status details rather then just its status code would this be the use of at @Embeddable? (Sorry for the poor book example.)

Putting ORM in now, might help me out with my spring app, rather then wait til later, as have a case that might, if i understand it correctly, benifit from this lazy load stuff.

G
 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another thing to keep an eye on: relationships vs. associations especially their directionality. Having bidirectional associations everywhere (in an attempt to mimic the capabilities of SQL) in the domain model can become a royal pain. Only make it bidirectional when you really have to. If there is a case where you have a 90/10 split think about modeling the directionality with the 90% case and for the 10% case have a finder method on the repository that returns the object on the other end of the association by returning it from memory or that materializes it from the DB (if it doesn't exist yet).

Inside most aggregates (e.g. order with its order lines) a unidirectional association (order -> order line) is sufficient.
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bi directional, as in being able to get an Author based on a Book?
If so, yeah I had noticed that it can be a pain, I think for my system I can keep these to a min and will be going from the "parent" to the "child" more then the other way around.
I am allowing a user to place comments, so in this case an object would have comments and from the comment I would like to display the user, so I can see at least one case.

G
[ April 20, 2007: Message edited by: Gavin Tranter ]
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, your example is a one-to-one example and not Embedded.

So I have one table that has the following fields

bid_id (pk)
user_id (fk)
bid_date (date)
currency_type (varchar2)
amount (number)


I can create a Bid object, and I might create a MonetaryAmount object. So the Bid object has



So I didn't put any mapping in there, but you can see that the MonetaryAmount will hold the attributes that are values in the same Bid table. MonetaryAmount would then be an embedded mapping. If I have other tables that also have currency_type and amount, I can re-use the MonetaryAmount in those other objects, and just override the column names that it will map to.

So Embedded objects are ways to create more than one object for the same table, but aslo be re-usable for other tables that might need it to. There is a lot of flexibility to Embedded objects and code you can write. What if you have to always save the amount in USD, in the table, but always want to display what the bid was actually made in with the amount being converted to the other currency type. Well with the MonetaryAmount object you can easily implement that.

Sorry, but won't be able to help contribute to this thread anymore, my fingers are tired.

Mark
 
Gavin Tranter
Ranch Hand
Posts: 333
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mark, Peer,
Thanks very much you have been most helpful

Gavin
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic