aspose file tools*
The moose likes JDBC and the fly likes advice on persistence Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Databases » JDBC
Bookmark "advice on persistence" Watch "advice on persistence" New topic
Author

advice on persistence

miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
i'm developing a very very small swing standalone home app

in my previous one i used hibernate; as i'd like to learn new things, i thought i could use either text files or jdbc; i've a little experience with sql: crud stuff
my app has very little things to persist: one class with four String fields and eventually an Enum; this class is added to a user's (there will be only two of them) Set

will this be a lot of work, if i use jdbc?

is this possible using just text files? How?

thanks in advance for any answers you might give


java amateur
graham king
Ranch Hand

Joined: Dec 30, 2004
Posts: 133
it's actually kinda fun writing the jdbc.

check out:


DAO Factory


write, revise, re-write, revise, again...<br />write, revise, re-write, revise, again...
miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
i read through all examples except last 3, because they dont fit my needs
now two other questions: i guess my persistent class IS a value object!


now, i guess that DAO stuff acts like a strategy pattern, no?

anyway, i think i only need to abstract persistence mechanisms from logic (and presentation). am i right?

just anotherclass (and those two are all i have to persist):

if on one hand i'd like to do it right (proper code easy to maintain and modify), one the other hand i dont want stuff i'll need not...
graham king
Ranch Hand

Joined: Dec 30, 2004
Posts: 133
miguel,

my persistence object is a value object

yep


that DAO stuff acts like a strategy pattern, no?

i think you're right.


abstract persistence mechanisms from logic (and presentation).


from the logic? of the example? sure, but, definately from the presentation.

you could over simplify it by using perhaps a delegate -> dao. the factory is nice in case you want to use multiple databases.

9.1 defines the factory
9.2 gives you access to a specific db
9.4 gives you access to a specific dao representing a table
9.6 shows you how to put it all together
[ August 15, 2006: Message edited by: graham king ]
miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
from the logic?

what i meant is that my classes from domain dont need to know how persistence is implemented: jdbc, hibernate or else
you could over simplify it by using perhaps a delegate -> dao


the factory is nice in case you want to use multiple databases.

like when i have one for testing and another for real?

BTW thanks for keeping talking
graham king
Ranch Hand

Joined: Dec 30, 2004
Posts: 133

like when i have one for testing and another for real?


not really. more like when you use a mySql and then later on someone asks you to use a sql server or oracle or something else. i've never had to do it, but, there's always a chance.

i think where you might be confused is with the connection properties. i know they're hard coded in the example, but, you really should have them in a properties file of some sort. (check out the ResourceBundle class in the java api. it gives you access to an apps properties when needed.) when you put em in a properties file you basically can switch between whichever database you want to without touching the code.

the delegate to dao is just another abstraction. i guess sorta like a struts action class. it kinda acts as a go between for jsp's. they, the jsp's, call the delegate, or perhaps the action class, and the delegate calls the dao's or hibernate or whatever.
graham king
Ranch Hand

Joined: Dec 30, 2004
Posts: 133
here's an ex of using the ResourceBundle


properties file
miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
thanks again, but as for persisting to a text file, is that a poor idea?
stu derby
Ranch Hand

Joined: Dec 15, 2005
Posts: 333
Originally posted by miguel lisboa:
thanks again, but as for persisting to a text file, is that a poor idea?


Not necessarily.

It can be an advantage to have the persisted state stored in a human-readable, human-modifiable mode, or it can be a sever disadvantage. depends on the app.

If you're not persisting anything particular complex. I've written apps, that gather settings information and used java.util.Properties.store(), then on restart use load().

On the other hand, if you need to discourage user poking at the persisted state, or the state is complex or big and you don't want to read it and write it all at once, then using a database can be just thing.

Besides the well-known external databases, such as MySQL, Oracle, and Postgres, be aware that there are now also embeddable JDBC databases, such as HSQL. They're written in java and (can be configured to) run inside your application, thereby avoiding the complication of making program users configure a connection to a database (and possibly having to set one up).

Some people will try to "split the difference" and use an XML file for persistence. While it can work, and even work well, in my experience it's usually better to go with either plain text at one end of the spectrum, or a true database technology like JDBC at the other.
miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
in my previous app i used, for a while, hsqldb for testing and mySql for real
for the moment i'm inclined to go with jdbc/mySql

we'll see...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: advice on persistence