dao questions

[Guest]

A lot of people recommend using the dao pattern for data access because it
makes it easy to change persistance strategy and abstracts away the
differences between datasources.

However I am somewhat confused about some of the implications this involves

concern 1:

Suppose you have a products table which contains infomation about your
products Lets say there are 3000 of them in the database and each product
record contains a description field which contains a very large description
of the product in a clob field

now everytime you want to list all products you have to instantiate 3000
objects with this *huge* description field in it, this seems very
inefficient performance and memory wise

I know core j2ee patterns recommends using a disconnected rowset and create
a RowSetWrapperList that creates instances only when needed, this improves
performance somewhat but you'd still have to fetch all fields and all
records of the table when maybe you'd only want to page thru a list of
productname and price field in a jsp page

how do you deal with these situations?
Ignore it and just Buy heaps and heaps of memory it's cheap anyhow? , Just
use jdbc for reading the stuff?


concern 2:

how do you handle relations? An object can have many relations, say a
TeamMember - Team relationship
Having a Set of TeamMembers in Team would seem intuitive, but then the dao
would also have to load all the TeamMembers, and TeamMember might have an
associated Role object which would also have to be loaded etc..
So that doesn't seem like an option
I suppose you could have a TeamMemberDAO.getByTeamID(int ..) and fix it that
way. But suppose Team would have a business method that required access to
its members would it call TeamMemberDao.getByTeamID ?, that doesn't feel
quite right
Or should you externalize all business logic and treat objects returned by
the dao only as data transfer objects, that doesn't feel right from an OO
point of view

This dao stuff feels kind of cumbersome right now, I'd appreciate if anyone
could shed some light on this

 

[Antti Salonen]

A lot of people recommend using the dao pattern for data access because it
makes it easy to change persistance strategy and abstracts away the
differences between datasources.

I would recommend it too, but maby not for small applications.

However I am somewhat confused about some of the implications this involves

concern 1:

Suppose you have a products table which contains infomation about your
products Lets say there are 3000 of them in the database and each product
record contains a description field which contains a very large description
of the product in a clob field

Sounds like place for lightweight pattern. Idea is to make normal
Product class, which contains all the data, and in addition LightWeightProduct
class, which contains only for example id, name and weight fields
(or whatever are needed eg. for listing).

concern 2:

how do you handle relations? An object can have many relations, say a
TeamMember - Team relationship

Have you considered object-relation mapping tools. For example hibernate
(http://hibernate.sourceforge.net/) is good. They have solutions like
lazy initialization of related objects (load them from db when they are
first needed).

Or should you externalize all business logic and treat objects returned by
the dao only as data transfer objects, that doesn't feel right from an OO
point of view

IMO this is not the way to go. If you want to think OO, business logic
belongs to domain model.

This dao stuff feels kind of cumbersome right now, I'd appreciate if anyone
could shed some light on this

I definitely recommend rich domain model and using of o/r mapping, if your
app is complex enough and you want to do OO. Mapping layers are usually quite
database independent and have rich set of features like tools for generating
mappings/schemas/classes, handles problematic persisting issues like
transactions and versioning etc. Basically they let you think more about
objects and business logic. But also there some learning to do with them
before you can get full advantage of them.


-antti

 

[iksrazal]

A lot of people recommend using the dao pattern for data access because it
makes it easy to change persistance strategy and abstracts away the
differences between datasources.

Another important reason is that you should encapsultate your business
logic _outside_ the dao. The dao just gets data without the caller
caring from where. In my experience it only works well using constant
strings defined elsewhere for your sql statements.

However I am somewhat confused about some of the implications this involves

concern 1:

Suppose you have a products table which contains infomation about your
products Lets say there are 3000 of them in the database and each product
record contains a description field which contains a very large description
of the product in a clob field

now everytime you want to list all products you have to instantiate 3000
objects with this *huge* description field in it, this seems very
inefficient performance and memory wise

Cache it, via a singleton or something. Lazy load it or static
initialize it. Product lists don't change often, right?

I know core j2ee patterns recommends using a disconnected rowset and create
a RowSetWrapperList that creates instances only when needed, this improves
performance somewhat but you'd still have to fetch all fields and all
records of the table when maybe you'd only want to page thru a list of
productname and price field in a jsp page

Reading the entire table into objects defeats rdbms I think. With a
whole lot of data, simply don't try to do it all in one call.

how do you deal with these situations?
Ignore it and just Buy heaps and heaps of memory it's cheap anyhow? , Just
use jdbc for reading the stuff?

There's a balance. The less remote calls the better, but don't try to
eliminate all of them.

concern 2:

Or should you externalize all business logic and treat objects returned by
the dao only as data transfer objects, that doesn't feel right from an OO
point of view

The dao only gets data. Do your buisiness logic via the builder
pattern or in your delegates. Methods should do only one thing and do
it well - getting your data in this case. Worry about the rest
elsewhere.

This dao stuff feels kind of cumbersome right now, I'd appreciate if anyone

could shed some light on this

Start looking at some code. Perhaps try downloading the code from this
book - best I've seen so far.

http://support.apress.com/books.asp?bID=1861005288&s=0&Go=Select+Book

iksrazal

 

[Rajesh Patel]

Have you considered using hibernate? Instead of coding the jdbc
directly you can create hibernate dao's that will handle all your
persistence. It can even be set up to dynamically create lazy
loading proxies so you don't have to load up the large objects
you are talking about.

hibernate.org.

Raj