Migración a Arquitectura J2EE
Mauricio
30 de Diciembre del 2004
Hola Gente,
Necesitaría que me ayudaran ya que participo de un proyecto de migración tecnológica, donde se esta evaluando llevar las aplicaciones cliente servidor a J2EE.
Me gustaria saber cuales son las alternativas posibles en cuanto a arquitectura, por ejemplo, donde conviene poner la capa de negocios, si conservarla en la base de datos o pasarla al modelo de clases. Ventajas y desventajas de cada alternativa.
Alguien conoce alguna bibliografia que me ayude?
Saludos
Mauricio
Necesitaría que me ayudaran ya que participo de un proyecto de migración tecnológica, donde se esta evaluando llevar las aplicaciones cliente servidor a J2EE.
Me gustaria saber cuales son las alternativas posibles en cuanto a arquitectura, por ejemplo, donde conviene poner la capa de negocios, si conservarla en la base de datos o pasarla al modelo de clases. Ventajas y desventajas de cada alternativa.
Alguien conoce alguna bibliografia que me ayude?
Saludos
Mauricio
albertodominguez
30 de Diciembre del 2004
Bueno, yo he migrado varias aplicaciones C/S a J2EE, sin EJBs. Como sabras, los EJBs implican un resiseño de la capa de persistencia (Base de datos). Como bien lo dicen en otro comentario, debes documentarte, sin embargo yo te transmito la decisión que tome en mis proyectos.
Con el fin de mantener compatibilidad hacia atrás con el sistema C/S y que pudieran convivir en el mismo ambiente, no modificamos el modelo E-R, sin embargo en presentación usamos el Patron MVC del framework Struts, que es muy flexible, y el acceso a las BD se desarrollo con el Patron DAO. Un ejemplo simple de una implementacion similar esta en el Libro de WROX, Jakarta Struts, que te lo recomiendo.
Suerte en tu proyecto
Con el fin de mantener compatibilidad hacia atrás con el sistema C/S y que pudieran convivir en el mismo ambiente, no modificamos el modelo E-R, sin embargo en presentación usamos el Patron MVC del framework Struts, que es muy flexible, y el acceso a las BD se desarrollo con el Patron DAO. Un ejemplo simple de una implementacion similar esta en el Libro de WROX, Jakarta Struts, que te lo recomiendo.
Suerte en tu proyecto
maramonar
30 de Diciembre del 2004
Menuda tarea tenes entre manos, je....
Lectura que te recomiendo:
J2EE Design and Development y J2EE without EJB, ambos de Rod Johnson....
Con respecto a la arquitectura, tema muy amplio.
Primero tendrían que definir que tipo de cliente tendrá la aplicación (web o rich)..eso determinará varias desiciones posteriores...si vas a utilizar clientes web, testear algunos de los frameworks MVC exitentes (struts, Spring-Web, etc)...determinar si tu aplicación será distribuida o necesitará acceso remoto, esto puede determinar si vas a necesitar usar EJB o no....determinar como vas a persistir los datos....en fin, el tema de la arquitectura es largo y por ahí la lectura de los libros que te mencioné más arriba te va a ayudar mucho.
Con respecto a la lógica en la DB o en una capa intermedia...pues la recomendación lógica es tener la lógica de negocios dentro de los objetos de tu dominio...esto sería así si uno arrancara con el desarrollo desde 0...pero, por ejemplo si esta lógica va a ser utilizada tanto desde esta aplicación como desde alguna otra aplicación 8legacy en VB o algo por el estilo) te va a convenir mantenerla en la DB....si tenes demasiados recursos invertidos en el desarrollo de esa lógica por ahí te conviene ir migrandola gradualmente.......en fin, espero haber ayudado un poco.
Lectura que te recomiendo:
J2EE Design and Development y J2EE without EJB, ambos de Rod Johnson....
Con respecto a la arquitectura, tema muy amplio.
Primero tendrían que definir que tipo de cliente tendrá la aplicación (web o rich)..eso determinará varias desiciones posteriores...si vas a utilizar clientes web, testear algunos de los frameworks MVC exitentes (struts, Spring-Web, etc)...determinar si tu aplicación será distribuida o necesitará acceso remoto, esto puede determinar si vas a necesitar usar EJB o no....determinar como vas a persistir los datos....en fin, el tema de la arquitectura es largo y por ahí la lectura de los libros que te mencioné más arriba te va a ayudar mucho.
Con respecto a la lógica en la DB o en una capa intermedia...pues la recomendación lógica es tener la lógica de negocios dentro de los objetos de tu dominio...esto sería así si uno arrancara con el desarrollo desde 0...pero, por ejemplo si esta lógica va a ser utilizada tanto desde esta aplicación como desde alguna otra aplicación 8legacy en VB o algo por el estilo) te va a convenir mantenerla en la DB....si tenes demasiados recursos invertidos en el desarrollo de esa lógica por ahí te conviene ir migrandola gradualmente.......en fin, espero haber ayudado un poco.