advice on persistence

[miguel lisboa]

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

[graham king]

it's actually kinda fun writing the jdbc.

check out:


DAO Factory

[miguel lisboa]

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!

package dominio;
 

public class Nota {

private String disciplina;

private String data;

private String notaPrevista;

private String notaAtribuida;



public Nota(String disciplina, String data) {

this.disciplina = disciplina;

this.data = data;

}



@Override

public boolean equals(Object obj) {

if (obj == null)

return false;

if (obj.getClass() != this.getClass())

return false;

Nota outro = (Nota)obj;

return this.disciplina.equals(outro.disciplina) &&

this.data.equals(outro.data);

}



@Override

public int hashCode() {
 
return 0; //TODO

}

 

public String getNotaAtribuida() {

return notaAtribuida;

}
 

public void setNotaAtribuida(String notaAtribuida) {

this.notaAtribuida = notaAtribuida;

}
 

public String getNotaPrevista() {

return notaPrevista;

}
 

public void setNotaPrevista(String notaPrevista) {

this.notaPrevista = notaPrevista;

}
 


public String getData() {

return data;

}
 


public String getDisciplina() {

return disciplina;

}
 


public void setData(String data) {

this.data = data;

}
 


public void setDisciplina(String disciplina) {

this.disciplina = disciplina;

}

}    

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

 package dominio;
 

 
import java.util.HashSet;
 
import java.util.Set;
 

 

 

public class Aluno {

private String nome;

private Set<Nota> notas = new HashSet<Nota>();
 


public Aluno(String nome) {

this.nome = nome;

}



public String getNome() {

return nome;

}
 

 
public Set<Nota> getNotas() {

return notas;

}

}   

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]

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]

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]

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]

here's an ex of using the ResourceBundle

package com.util;
 
import java.util.ResourceBundle;
 
public class Constants {
  protected static ResourceBundle resourceBundle = null;
  public static final String DEFAULT_DS_CON = "default.ds.con";
  public static String DEFAULT_DS_CON_VALUE = "";
  static {
try {
    resourceBundle = ResourceBundle.getBundle("pathToMyUtilFile"); // .properties is implied
    DEFAULT_DS_CON_VALUE = resourceBundle.getString(DEFAULT_DS_CON);
  } catch(Exception e) {
System.err.println("Caught exception getting util.properties resource bundle.");
    }
}
}
 
//above is accessed in another file like:
Constants.DEFAULT_DS_CON_VALUE;  //which translates to the below

properties file

default.ds.con=jdbc:cloudscape:rmi://localhost:1099/CoreJ2EEDB

[miguel lisboa]

thanks again, but as for persisting to a text file, is that a poor idea?

[stu derby]

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]

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