Representación del modelo abstracto
Cuando diseñamos una aplicación, se nos crean en la mente un montón de objetos que vemos que deberán ser necesarios: usuarios, facturas, documentos,... por poner algunos típicos. Conforme empezamos a estudiar el dominio de la aplicación completamos más la foto mental, y empezamos a realizar esquemas escritos sobre las relaciones entre ellos, y averigüar además qué comportamiento debe tener cada uno. Esto me refiero a que lo hacemos, auqnue sea mentalmente, mientras hacemos la captura de requisitos. Yo por lo menos, no puedo evitarlo, ni quiero evitarlo.
Posteriormente, hay un momento en que nos decidimos a realizar en esquema entidad-relación, o un diagrama UML de las clases del sistema, o una presentación simple con las figuras que nos aparecen en la aplicación. Y antes o después, según los gustos de cada uno o la metodología utilizada, realizaremos el interfaz de usuario.
Vayamos al típico caso de aplicación compleja, para la web (por lo menos es típico para mi, claro ;) ), y que se desea realizar mediante una estructura de tres niveles. Aquí tienes muchas opciones, pero centrémonos en la capa del modelo. ¿o no hay capa de modelo?
He visto casos donde se define el modelo de base de datos, y se hacen clases que representan prácticamente de manera unívoca las tablas. Otros donde desde la interfaz se generan las acciones que se ejecutan en el controlador y ahí se hace lo que se puede para realizar la acción.
A mí me gusta tener claro primero el modelo abstracto, e implementar este. Luego puedes ir en dos direcciones. Hacia la base de datos y desde la interfaz al API expuesto por el modelo. Pero después está el tema de las sesiones WEB, ¿qué guardas en la sesión? Debes guardar la mínima información para asegurar que en la siguiente acción del usuario vas a tener el modelo exactamente igual a como lo dejó la acción anterior.
Luego "solo" hay que bajar de esta abstracta explicación a picar código...
Mi Twitter
Interesante post.
ResponderEliminarUna vez que tienes la capa de modelo, ¿Quién se encarga de la persistencia? ¿Lo haces desde el propio modelo? ¿Metes una capa por debajo para independizar el modelo de la base de datos?
Bueno, lo más sencillo es crear una capa DAO (Data Access Object). Sobre esto hay mucha bibliografía en temas de patrones.
ResponderEliminarO puedes hacer persistente el modelo mediante alguna herramienta de persistencia objeto-relacional, por ejemplo, Hibernate. Personalmente me gusta más la primera idea, sobre todo si haces aplicaciones WEB que necesiten exprimir al máximo la velocidad y eficiencia.
Pero lo puedes hacer de mil maneras, todo depende del problema y su dominio.
Espero que no te importe que te siga preguntando.
ResponderEliminarHibernate y similares no me convencen, porque te fuerzan a controlar la base de datos cosa que, en muchas ocasiones, no puedes hacer (las tablas son las que son y no las puedes modificar).
Con respecto a la capa con los DAOs, siempre he tenido una duda. ¿Los DAOs deben devolver instancias de los objetos de modelo? Si es así, al final tienes una capa inferior (la de acceso a datos) dependiendo de una capa superior (la de modelo). Si no es así, ¿qué devuelve los DAOs?
Bueno, pues la comunicación entre modelo y DAO tienes muchas opciones. A mi la que más me gusta es que devulevan datos simples (lo más simples posibles) y que sea el modelo la que se encarga de darles sentido dentro del mismo.
ResponderEliminarEl DAO no debería conocer los objetos del modelo.
Seguimos...
ResponderEliminarEn mi modelo tengo una clase Libro con atributos Id, Título y Autor. ¿Qué tendría en el DAOs?
Una opción sería esta:
class ArticuloDao
{
String getAutor(int id);
String getTitulo(int id);
}
Pero esto te obliga a lanzar una consulta a la base de datos por cada atributo que quieras inicializar, y si la clase tiene 20 atributos y vas a crear 500 instancias, son unas cuantas consultas.
Y la otra opción... ¿cuál es la otra opcion?
Bueno, a ver, en realidad que tengas en tu modelo métodos sueltos para acceder a los atributos, no significa que los debas leer de la base de datos por separado.
ResponderEliminarEl DAO no tien por qué seguir fielmente a los objetos del modelo. Depende de su uso.
Por ejemplo....
Quizás tengas un DAO mejor con un método que te devuelve una lista con los datos de los artículos, por tanto solo una consulta a BBDD, y depues se creen la lista de Artículos....
Pero creo que no es el lugar adecuado para discutir estas cosas. Te invito a que acudas a Planeta codigo, a sus foros. Ahí suelo andar a menudo y mucha más gente que sabe mucho más que yo. Pregunta lo que quieras, y hay posts interesantes.
Salu2