aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Should an Object look itself up from db? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Should an Object look itself up from db?" Watch "Should an Object look itself up from db?" New topic
Author

Should an Object look itself up from db?

Warren Bell
Ranch Hand

Joined: Dec 20, 2000
Posts: 56
I currently create objects from a db in a service layer using a DAO like this:

int primaryKey = 11
Object order = orderDao.getOrder(primaryKey);

Can the object look itself up from the db? something like this:

int primaryKey = 11
Order order = new Order(primaryKey);
order.getOrder();

The DAO would be in the getOrder() method of the object itself. Is this a good or bad design? and is there some sort of pattern or cleaner way of having an object created from a db using a DAO? My service layer gets very bloated.

Thanks,

Warren
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Bad design, I need to think before understand what it is, people should not need to think (much) when looking at code.

If you want to do that you should use static method Order.getOrder(String pk);
http://martinfowler.com/eaaCatalog/activeRecord.html

I don't like Active Record pattern, because I don't like data-driven pattern (including DAO).

Take a look at Domain-Driven Design and Repository pattern.


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
What does your service layer get bloated by?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Warren Bell
Ranch Hand

Joined: Dec 20, 2000
Posts: 56
My service layer gets bloated with object creation. I have quite a few large objects that need to be constructed from different data sources, and use different DAOs. I don't like how I am doing it, but I have never figured out where else it could be done. I thought that I could do it in the object itself.

I will take a look at the two patterns Kengkaj mentioned.

Any other suggestions?

Thanks

Warren
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Can you give example code for such a construction of a large object?
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
For complex object creation you should encapsulate in Factory [Domain-Driven Design].
Warren Bell
Ranch Hand

Joined: Dec 20, 2000
Posts: 56
For Example, I have a data grid that lists Orders. The steps I have to take are.

1. Retrieve a list of orders from data source A based on what page data grid is displaying and how many records are to be shown.
2. Retrieve the same orders from data source B.
3. Map the order status of orders from data source B to orders from data source A.
4. Update data source A with the mapped order status from data source B
5. Sort orders based on input from data grid
6. Display orders.

I have full access to data source A but I have only SELECT access to data source B. The code I use to do this is about 100 lines and works fine. I can clean it up some, but I don't no where this type of code should be placed. I have thought about encapsulating the above type of code in its own class and using some kind of variation of the Command Pattern or a simple interface of some sort. I have about 50 different situations like the above and have been doing this sort of thing in 4 different service classes.

Warren
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Mhh, hard to tell without being there and personally feeling the forces, but I'd probably also look into the Repository pattern from "Patterns of Enterprise Application Architecture", and perhaps into the Interpreter pattern.
Warren Bell
Ranch Hand

Joined: Dec 20, 2000
Posts: 56
The Repository pattern looks like what I was talking about. I did not see the exact example, but I saw a similar example in an article at:

http://in.relation.to/Bloggers/RepositoryPatternVsTransparentPersistence

They showed something like this:

lineItemDAO.findAllForOrderId(order.getId())

being done in a repository like this:

OrderRepository.getLineItems(order)

which is kind of what I do now, but I am calling it a service instead of a repository. They then inject this OrderRepository into the order object so all they have to do is this:

order.getLineItems()

Is that basically the Repository pattern? This is what I was thinking of doing, but I wanted to create the order object by looking up itself using a Service/Repository internally. It looks like the difference being is that this pattern is for an object that needs to look up internal members versus creating the object itself. Plus would you have to have two methods, one for retrieving line items from the db and one for simply retrieving them from the object itself? I am guessing I could just use this Service/Repository in a Factory and create my order objects that way.

Any other thoughts?

Warren




Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
I'm not sure why do you want to use Active Record pattern, looking up object from Class method is Active Record pattern.
How does that help your design/implementation?

Warren Bell wrote:The Repository pattern looks like what I was talking about. I did not see the exact example, but I saw a similar example in an article at:

http://in.relation.to/Bloggers/RepositoryPatternVsTransparentPersistence

They showed something like this:

lineItemDAO.findAllForOrderId(order.getId())

being done in a repository like this:

OrderRepository.getLineItems(order)

which is kind of what I do now, but I am calling it a service instead of a repository. They then inject this OrderRepository into the order object so all they have to do is this:

order.getLineItems()

Is that basically the Repository pattern?

Well, the example is completely wrong, if it's talking about Repository in Domain-Driven Design.
Before implement Repository, one must know concept of Aggregate.

Repository should be like:
OrderRepository.getOrder(orderId);

and then we can get LineItems by navigating association: order.getLineItems().
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Should an Object look itself up from db?