Java - dao

Hola a todos!!
Estoy haciendo un proyecto, y mi problema es que no se como organizar las clases... En internet he visto que para acceder a la base de datos necesito una clase especial y un bean que te representa una unidad de informacion de la base de datos y que el dao se encarga de crear el bean y todas las tareas de almacenar en la base de datos. Yo lo unico que conocia en java era la division , modelo vista y controlador.. Entonces si yo tengo mi vista con todos mis componentes visuales definidos y mi controlador , el modelo que pinta realmente?? Porque para mi mi modelo lo unico que me deberia de hacer es hacer operaciones con la base de datos... Ahh y el controlador puede llamar directamente al dao sin pasar por el modelo?? o obligatoriamente hay que llamar al modelo y despues este se encargue de llamar al daooo... Estoy echa un lio... a ver si me lo podeis aclarar.. Un saludo y gracias de antemano.

A ver Loly... la clase especial que dices se trataría solamente de una clase un poco independiente que te crease o devolviese una conexión a una base de datos.

Esa conexión sería la que usarían las clases DAO para poder acceder a la BD.

Por otro lado, la vista NUNCA accede directamente a la capa DAO, siempre accede a datos a través del controlador.

Como tú dices, el modelo simplemente tiene que hacer el acceso a datos, solamente eso, ninguna otra operación. Ya el controlador es el que se encarga de hacer las operaciones necesarias o convenientes con esos datos.

Te pongo un ejemplo sencillo de controlador y modelo, ya que la vista sí la tienes más clara.
Supongamos que tenemos una entidad Cliente que tiene como campos nombre, apellidos y edad (sencillito pa no escribir mucho).
Pues en tu clase controlador, tienes este método por ejemplo:

cliente.save(String nombre, String Apellido, String edad);

Ese método no debe hacer más que llamar a un método de tus clases dao que ejecuten la sql correspondiente para salvar esos datos, de esta forma:

clienteDAO.save(Cliente cli);

De forma que le pasas un objeto complejo (clase Cliente) y ese método lo descompone como le es necesario para luego crear la select correspondiente y ejecutarla.

En este caso, parece un poco repetitivo o redundante tener que hacer un método que llama a otro simplemente para almacenar ciertos datos en la BD, pero en otras acciones sí tiene mucha más lógica. No te encierres en buscarle el sentido, simplemente hazlo de esa forma porque poco a poco te irás dando cuenta de su utilidad.
Por ejemplo digamos que tienes una clase Persona que usas para una aplicación que se encarga de seleccionar gente para realizar encuestas. En su clase DAO tendrás métodos en los que puedas preguntar su edad, su sexo, su localidad, su profesión, etc. Y en las clases controlador tendrías un simple método isObjetoDeEncuesta(long idPer); que te devuelve simplemente un booleano que te dice si esa persona es objeto de una determinada encuesta o no. Dentro de ese método llamarias a los DAO para obtener la edad el sexo etc... de la persona coincidente con el idPer que le pasas al método. Esos métodos DAO solo te devuelven los valores que tu encuentras en la BD y con ellos, en el controlador, haces las comparaciones o cálculos necesarios para saber si esa persona es válida para una encuesta o no.
Digamos que las SQL (o cualquier tipo de consulta a BD) deben estar encapsuladas en el modelo, nunca debe haber una SQL en la vista o en el controlador. Nunca el controlador debe consultar directamente a la BD y nunca la vista puede acceder a clases DAO.
Aunque no le veas todo el sentido que tiene si tu aplicación es sencilla, piensa que esa aplicación dentro de un futuro podría crecer, y tener encapsuladas las consultas en un mismo paquete te resolvería muchos problemas. El simple hecho de cambiar de nombre un campo en una tabla, haría que si no tienes bien organizado el código, te hartases de buscar donde tienes que cambiar eso, pero teniendolo bien organizado, sabrías que debe estar en el paquete DAO, en la clase correspondiente a la entidad de la cual se cambió ese campo.
Me enrollomucho sin saber realmente cuales son tus dudas más concretas, coméntamelas y a ver si podemos aclarar un poco las cosillas.