¿Cómo diseñar y diseñar una aplicación web Java/Java EE?

Question

Soy un desarrollador de Java con casi 5 años de experiencia en Struts, Spring e Hibernate.

Tenemos un nuevo proyecto en unos días. Tenemos los requisitos completos con nosotros y haremos este proyecto utilizando Spring MVC, Spring y Hibernate.

Se me ha pedido que diseñe y diseñe toda la aplicación web. Diseñar y crear un arquitecto es algo que no he hecho hasta ahora en mi carrera. Y no sé cómo hago esto y dónde comenzar, qué herramientas usar y demás. No sé ni siquiera las A, B, C de diseño y arquitectura.

Usted se estará preguntando por qué incluso me pidieron que hiciera esto en primer lugar. El asunto es que se me dio la oportunidad de hacer esto y en cada etapa me controlarán y haré que mis superiores revisen el diseño.

Así que cualquier sugerencia, ideas y pasos para comenzar y seguir adelante son bienvenidos.

Answer 1

puedo añadir mis 2 centavos de mis propias experiencias (aunque es más de una compilación de las mejores prácticas de desarrollo, puede que le resulte útil para mantenerlos en cuenta al diseñar su aplicación):

• Hay no one-size-fits-all diseño
• Trate de mantener la aplicación lo más ligera posible.
• Utilice Maven/Gradle para administrar dependencias
  • No confíe excesivamente en IDE. Asegúrate de que tu proyecto se construya sin IDE (si estás usando maven/gradle, :) Intentará abrir tu proyecto con IDEA, Netbeans y Eclipse.
• Para las tecnologías mencionadas anteriormente, appfuse es un buen punto de partida.
• Diseñe su base de datos/entidades primero
• Use las bibliotecas de forma sensata y juiciosa. NO los use en exceso.
• No se olvide de escribir JUnit/TestNG (al menos para la capa de servicio) la aplicación
• prueba en todos los principales navegadores (no sólo su preferido :)
• Determinar el número de usuarios totales y el número de usuarios de su aplicación web concurrente tendrá.
  
  • Luego, decida si necesita almacenar en caché o no.
  • usará la agrupación del servidor de aplicaciones o no.
• Seleccione el servidor de aplicaciones en función de sus capacidades y lo más importante "sus necesidades de
  • Tomcat/embarcadero son absolutamente bien para la mayoría de los casos
• evitar el uso de API específicas de aplicaciones en servidores
• Utilice las interfaces/anotaciones JPA incluso si utiliza Hibernate como implementación de JPA
• Sea extremadamente prudente al mapear las relaciones en las entidades. Decida qué propiedades y relaciones se cargarán perezosamente y cuáles se cargarán ansiosamente
• Tenga en cuenta la seguridad de las aplicaciones al diseñar la aplicación. La seguridad de primavera es una excelente opción.
• Nunca abuse de HttpSession. No almacenar demasiado en ella.
• Keep entities Serializable. Enforce los desarrolladores utilizar toString(), hashCode() y equals()
• No se olvide de utilizar la versión de control a partir del día 1
• apenas no asuma que la primavera/hibernación/primavera-mvc será la mejor opción para usted. crear una pequeña prueba de conceptos con al menos 3 a 4 opciones.
• Trate de automatizar la integración/construcción/desplegar con herramientas de CI como Jenkins
• Check y Tune SQL generado por Hibernate (en su momento)
• No permita que la fluencia lógica de negocio en la capa de vista. Odio scriptlets jsp? Considera Velocity/Freemarker. JSP no es la única opción.
• externalizar la configuración específica del entorno mediante Spring's PropertyPlaceholderConfigurator.
• Si es posible, intente integrar con el mecanismo de autenticación de usuario existente (como LDAP/OpenID) en lugar de escribir el suyo propio. Esto le evitará reinventar la rueda y que sus usuarios recuerden otro conjunto de nombre de usuario y contraseña.

Answer 2

Examine el sitio de modelado ágil que impulsa el modelado "lo suficiente". Tienen algunas pautas geniales que incluyen un "proceso de modelado ágil" completo desde la recopilación de requisitos hasta el diseño/desarrollo.

http://www.agilemodeling.com/

http://www.agilemodeling.com/essays/amdd.htm

http://www.agilemodeling.com/essays/agileArchitecture.htm

http://www.agilemodeling.com/essays/agileAnalysis.htm

http://www.agilemodeling.com/essays/agileDesign.htm

cuanto a las herramientas, me encanta Visual Paradigm. Es relativamente barato (en comparación con otras herramientas). Hay una variedad de herramientas de modelado gratuitas (google es tu amigo), pero ninguna se compara con Visual Paradigm, y por poco que cueste, bien vale la pena. Si mi empleador no pony el efectivo, lo compraría yo mismo ... :)

Answer 3

Hay varias cosas que necesitará para los documentos de diseño de la arquitectura. No es una tarea fácil, sino un apoyo para aprovechar la oportunidad. Dado que esta es una pregunta tan grande, con suerte estos enlaces pueden ayudarlo a comenzar y puede refinar las preguntas después de mojarse los pies.

Metodología

La metodología utiliza afectará las tareas que se toma en primer lugar. Waterfall es una metodología popular pero obsoleta. Una metodología más nueva es ágil que tiene varias caras. Mi favorito es Scrum Agile para desarrollar software de cualquier tamaño.

Diagramas

Diagrams son una de las maneras más eficaces para representar el sistema en su conjunto y como componentes individuales. El tipo de diagramas que crea depende del sistema. Generalmente hay Diagramas de Estructura, Diagramas de Comportamiento, Diagramas de Interacción y toneladas de otros. Estos diagramas muestran las piezas del sistema como un todo, el diseño físico de cada componente y/o el diseño lógico, el flujo de comunicación, el flujo del procedimiento, etc.

Documentación

documentación es así como suena, los documentos y los documentos que tienen descripciones de proyectos, Alcance, Casos de usuario, diagramas de secuencia, y cualquier otro documento que describe el proyecto o piezas del proyecto.

Answer 4

Eche un vistazo a Robert Martin's (aka Uncle Bob) Clean Architecture. Here's una visión general rápida. Usando este enfoque, usted será capaz de diferir detalles como Spring o Hibernate para un momento posterior y enfocarse más en la lógica comercial. O incluso migrar de Spring a Java EE sin tocar su negocio y la lógica de la aplicación. También obtendrá una aplicación comprobable que cumpla con los principios SÓLIDOS, sin demasiado esfuerzo adicional.

Acabo de crear una aplicación de esta manera y debo decir que estoy muy contento con ella. Podría fácilmente portarlo a una aplicación de escritorio o móvil, o cambiar el módulo de almacenamiento. Los detalles que dependen de la política recorren un largo camino. También promueve el pensamiento en una especie de API y, cuando se aplica correctamente, hace que sus módulos sean muy reutilizables.

Martin llega a decir que los detalles como los marcos son molestos y no forman parte de su arquitectura. Creo que pertenecen a la arquitectura, pero a un nivel diferente. A menudo desea incluir marcos en una etapa temprana para poder producir una porción delgada de una aplicación en funcionamiento para demo a sus usuarios. O cuando conoce sus marcos por adelantado y no hay discusión sobre ellos, como en mi caso. Pero podría considerarlo como arquitecturas de software separadas, cuando se combinan crean la arquitectura de su aplicación.

Answer 5

He editado un nuevo libro sobre Spring, Hibernate y Data Modeling que responderá a su consulta sobre el aspecto de diseño de una aplicación web Java EE. Normalmente, una aplicación web Java EE tiene 5 niveles: cliente, presentación, servicio comercial, acceso a datos y recurso (entidad). El libro se centra en cómo diseñar y desarrollar cada uno de estos niveles tomando ejemplos de todas las relaciones de modelado de datos utilizando Spring e Hibernate. Como descarga, se proporciona una aplicación web completa donde encontrará información sobre la gestión de cada relación de escenario de modelado de datos.

Veamos una entidad independiente simple. Para gestionar la entidad, deben diseñarse métodos como crear, leer, actualizar, eliminar y buscar todos los registros. Entonces, si vamos hacia abajo, la creación de la entidad constituye el primer paso. A continuación, observamos el Repositorio que tiene los métodos descritos anteriormente. Más arriba viene el nivel de servicio comercial y luego el controlador REST Spring que está basado en JSON. La tarea restante implica codificar la página JSP y las llamadas JQuery AJAX al controlador REST.

Puede encontrar más información sobre el libro here

Answer 6

more details

1. Antes de embarcarse en la codificación de obtener los requerimientos del negocio hacia abajo. Cree una lista completa de las funciones solicitadas, ejemplos de capturas de pantalla (si están disponibles), diagramas de casos de uso, reglas comerciales, etc. como documento de especificación funcional.Esta es la fase en la que los analistas y desarrolladores de negocios harán preguntas sobre los requisitos de interfaz de usuario, requisitos de integración de niveles de datos, casos de uso, etc. También priorizará las funciones en función de los objetivos comerciales, los plazos de entrega y las iteraciones necesarias para la implementación.

2. Prepare un documento de especificación técnica basado en la especificación funcional. El documento de especificaciones técnicas debe cubrir: Propósito del documento: p. Este documento enfatizará la funcionalidad del servicio al cliente. Descripción general: Esta sección cubre básicamente información de fondo, alcance, inclusiones y/o exclusiones, documentos referenciados, etc. Arquitectura básica: analiza o referencia el documento de la arquitectura de referencia. Respuestas a preguntas como ¿Escalará? ¿Se puede mejorar este rendimiento? ¿Es extensible y/o mantenible? ¿Hay algún problema de seguridad? Describe los sectores verticales que se utilizarán en las primeras iteraciones y los conceptos que se probarán en cada segmento. Etc. Por ejemplo, ¿qué paradigmas MVC [modelo-1, modelo-2, etc.] deberíamos usar? ¿Deberíamos usar Struts, JSF y Spring MVC, etc. o construir nuestro propio marco? ¿Deberíamos usar un delegado comercial para desacoplar el nivel medio con el nivel del cliente? ¿Deberíamos usar AOP (Programación Orientada a Aspectos)? ¿Deberíamos usar la inyección de dependencia? ¿Deberíamos usar anotaciones? ¿Necesitamos internacionalización? Etc. Supuestos, dependencias, riesgos y problemas: resalte todas las suposiciones, dependencias, riesgos y problemas. Por ejemplo, enumere todos los riesgos que puede identificar. Alternativas de diseño para cada requisito funcional clave. También discuta por qué se eligió una alternativa de diseño particular sobre las otras. Este proceso alentará a los desarrolladores a analizar las posibles alternativas de diseño sin tener que saltar a la solución obvia, que podría no ser siempre la mejor. Lógica de procesamiento: analice la lógica de procesamiento para el nivel del cliente, el nivel medio y el nivel de datos. Donde sea necesario agregar diagramas de flujo del proceso. Agregue cualquier condición previa al proceso y/o condiciones posteriores al proceso. Diagramas UML para comunicar el diseño a otros desarrolladores, diseñadores de soluciones, arquitectos, etc. Por lo general, se requieren diagramas de clase y diagramas de secuencia. Los otros diagramas se pueden agregar para cualquier caso especial. Diagrama de diagrama de estado: útil para describir el comportamiento de un objeto en varios casos de uso Diagrama de actividad: útil para expresar operaciones complejas. Apoya y fomenta el comportamiento paralelo. Diagrama de diagrama de actividad y estado son beneficiosos para el modelado de flujo de trabajo con programación de múltiples hilos. Diagramas de colaboración y secuencia: utilice un diagrama de colaboración o secuencia cuando desee observar el comportamiento de varios objetos en un solo caso de uso. Si desea ver un solo objeto en varios casos de uso, utilice el gráfico de estado. Diagramas de objetos: los diagramas de objetos muestran instancias en lugar de clases. Son útiles para explicar en detalle algunos objetos complicados, como destacar relaciones recursivas. Enumere los nombres de los paquetes, nombres de clases, nombres de bases de datos y tablas con una breve descripción de su responsabilidad en forma tabular.

3. Prepare un documento de estándares de codificación para todo el equipo para promover la coherencia y la eficiencia. Algunas prácticas de codificación pueden degradar el rendimiento, por ejemplo: Uso inapropiado de la clase String. Utilice StringBuffer en lugar de String para las mutaciones de cálculo intensivo. Código en términos de interfaz. Por ejemplo, puede decidir que LinkedList es la mejor opción para alguna aplicación, pero luego decide que ArrayList podría ser una mejor opción. Enfoque erróneo ArrayList list = new ArrayList(); Enfoque correcto Lista de lista = nueva ArrayList (100); Establezca la capacidad inicial de una colección de forma adecuada (por ejemplo, ArrayList, HashMap, etc.). Para promover la coherencia, defina estándares para nombres de variables, nombres de métodos, uso de registros, posiciones de llaves, etc.
4. Prepare un documento de revisión de códigos y plantillas para todo el equipo. Veamos algunos de los elementos que la revisión del código debe cubrir: Declaración de variable adecuada: p. instancia frente a variables estáticas, constantes, etc. Problemas de rendimiento: p. Utilice ArrayList, HashMap, etc. en lugar de Vector, Hashtable cuando no haya problemas de seguridad de subprocesos. Problemas de memoria: p. Ejemplificación incorrecta de objetos en lugar de reutilización de objetos y agrupación de objetos, sin cerrar el recurso valioso en un bloque finally, etc. Problemas de seguridad del subproceso: p. Las clases de Java API como SimpleDateFormat, Calendar, DecimalFormat, etc. no son seguras para hilos, declarar variables en JSP no es seguro para subprocesos, almacenar información de estado en la clase de acción de Struts o el servlet de subprocesos múltiples no es seguro para subprocesos. Gestión de errores: p. Reexpedición de excepción sin excepción original anidada, métodos EJB que no lanzan la excepción EJB para excepciones del sistema, etc. Uso de estándares de codificación: p. sin usar frameworks, se usa System.out en lugar de log4j, etc. Problemas de diseño: No se reutiliza el código, no se separa claramente la responsabilidad, no se usa la herencia para obtener la reutilización del método, los servlets realizan el acceso directo a JDBC en lugar de usar DAO (Objetos de acceso a datos), código HTML en la acción Struts o clases de servlet, servlets utilizados como clases de utilidad en lugar de como un controlador de flujo, etc. Documentación del código: ej. Sin comentarios, sin archivos de encabezado, etc. Errores: p. Llamar a setAutoCommit dentro de la transacción gestionada por contenedor, OR binario "|" utilizado en lugar de lógico O "||", confiando en pasar por referencia en llamadas remotas EJB, ResultSet no se cierra en excepciones, métodos EJB que no lanzan EJBException para excepciones de sistema etc.
5. Prepare documentos adicionales de directrices opcionales según los requisitos para ser compartidos por el equipo. Esto promoverá consistencia y estándares. Por ejemplo: Pautas para configurar el entorno de desarrollo J2EE. Directrices para el sistema de control de versiones (CVS, VSS, etc.). Pautas para los pasos de implementación, la configuración del entorno, los objetivos de las hormigas, etc. Directrices para el modelado de datos (cualquier norma de la empresa). Pautas para el manejo de errores. Pautas para el diseño de la interfaz de usuario. documento general de proyectos, software de documentos de proceso de desarrollo, etc.

Answer 7

hay una buena entrada en el blog por @tom en reflectoring.io Hace poco leí que pueden ayudarle. ¡Me ayudó!

A Checklist for setting up a Java-based Software Architecture

Aquí está la lista de temas de alto nivel discutido,

• Arquitectura Estilo
• back-end Preocupaciones
• Frontend Preocupaciones
• Operaciones Preocupaciones
• El desarrollo se refiere

Gracias