| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos |
Artículo "Buenas prácticas en J2EE. Primera parte."
Este artículo contiene la primera parte de un informe que explica técnicas de gran utilidad para el desarrollo con la plataforma J2EE. Aplicando estas técnicas, podemos disminuir la dificultad y el costo de este tipo de desarrollo y mejorar el rendimiento, calidad, flexibilidad y escalabilidad de los sistemas resultantes.
Artículo "Buenas prácticas en J2EE. Primera parte." (continuación)
3. BUENAS PRÁCTICAS DE PROGRAMACIÓN. Por décadas, la etapa de programación fue una fase larga y realizada de manera contigua. Sin embargo, la mayoría de metodologías modernas rompen esta etapa en iteraciones más pequeñas, para reducir su riesgo y complejidad. Como consecuencia, los programadores necesitan escribir código altamente flexible y reusable y hacerlo muy rápidamente, lo que se logra aplicando las técnicas que se explican en este apartado. 3.1. Buena práctica número 5. Utilice patrones de diseño probados Los patrones de diseño están entre los recursos más importantes para arquitectos y programadores ya que pueden usarse como se proponen o aplicarse a nuevos contextos. Los patrones están probados y son reusables. Proveen un lenguaje común para expresar la experiencia en programación. En pocas palabras, los patrones de diseño ahorran tiempo, dinero y esfuerzo. Por brevedad, sólo presentamos algunos de los patrones J2EE más importantes. Para una referencia más completa, consulte el catálogo de patrones J2EE de Sun. “Session Façade” (Fachada de sesión). Las aplicaciones EJB de grado fino son muy propensas a presentar una sobrecarga en las comunicaciones. Las fachadas de sesión proveen una capa de acceso a servicios que oculta la complejidad de las interacciones subyacentes y combina muchas comunicaciones lógicas en una única comunicación física, mejorando el rendimiento. MVC. El patrón de diseño Modelo-Vista-Controlador desacopla las capas de acceso a datos, presentación de los datos e interacción con el usuario. Los beneficios que resultan son un mantenimiento más sencillo porque hay menos dependencias entre componentes, una mayor reusabilidad pues los diferentes componentes implementan funciones distintas y una configuración más sencilla, ya que se pueden implementar nuevas vistas sin cambiar ningún código subyacente. “Value Objects” (Objetos de valor). Los objetos de valor son una única representación de todos los datos que se necesitan en una llamada a un EJB. Combinando todos los datos requeridos por una serie de llamadas, se puede ejecutar una única llamada remota en vez de muchas, aumentando el rendimiento global de la aplicación. “Data Access Objects” (Objetos de acceso a datos). Utilice un objeto de acceso a datos para abstraer y encapsular todo el código de acceso al origen de datos (normalmente, una base de datos). El objeto de acceso a datos gestiona la conexión con dicho origen de datos para recuperar y guardar datos, impidiendo que la lógica de acceso a datos se mezcle con la lógica del negocio. “Service Locator” (Localizador de servicios). Las aplicaciones empresariales necesitan el uso de componentes distribuidos. A menudo, es una tarea difícil y costosa obtener referencias a los componentes, como por ejemplo a una interfaz “home” EJB. En su lugar, se pueden gestionar dichas referencias a partir de un localizador de servicios que centralice las búsquedas de objetos distribuidos. Algunos beneficios de ello es contar con un único punto de control y con un punto adecuado para colocar una caché. 3.2. Buena práctica número 6. Automatice el proceso de construcción En un entorno de desarrollo empresarial, el proceso de construcción de una aplicación (“build process”) puede resultar muy confuso. Las interrelaciones entre archivos, los programadores que se centran en un único aspecto y los componentes de software ya empaquetados son factores que se añaden a la complejidad de dicho proceso. Si el proceso se ejecuta de forma manual, se pueden pasar incontables horas intentando descubrir como construir todos los componentes en el orden correcto. Por ello, es mucho mejor automatizar este proceso, para lo cual se deben considerar tres aspectos importantes: Se deben escoger herramientas adecuadas para dicha automatización. El proceso de desarrollo y el proceso de construcción deben interoperar bien. El proceso de construcción debería notificar el éxito o fracaso y permitir configurar los criterios que definen este éxito o fracaso. Si usted trabaja con la línea de comandos, debería usar una herramienta de construcción. Hoy en día, Ant es la herramienta escogida por los programadores de Java en todo el mundo. Ant es una herramienta de construcción extensible que está escrita en Java. Es un proyecto de código abierto de Apache Jakarta que se ejecuta sobre múltiples plataformas y puede contribuir en gran medida a la flexibilidad del proceso de construcción.
Ir a la página: 1 2 3 4 5 6 7 Siguiente >>
Versión para imprimir
| Inicio | Perfil | Servicios | Offshore | Recursos | Mapa del sitio | Contáctenos| |