libros - javafx tutorial netbeans

Cómo mejorar la productividad al desarrollar aplicaciones web basadas en Java EE (14)

A menudo se menciona que RoR y marcos similares basados en lenguajes dinámicos son entornos más productivos, pero estoy realmente interesado en saber si hay datos duros para respaldar esto. Esto no sería fácil, ya que uno debe estar seguro de que ella no está comparando manzanas con naranjas. Cosas como el tipo de proyecto (web 2.0, aplicación empresarial) y el tamaño del equipo deben tenerse en cuenta. Sin embargo, para proyectos pequeños, es más que evidente que dichos marcos son mucho más productivos que Java EE. Esta es una breve lista de argumentos utilizados para respaldar esto y lo que puede hacer por ellos en el mundo Java.

Ruby es un lenguaje más intuitivo y conciso. Puedes hacer lo mismo con mucho menos código.

No creo que pueda tener lo mismo en Java, a menos que use un lenguaje dinámico que se ejecute en la JVM (JRuby, Scala, Groovy). De lo contrario, su IDE puede ayudar. En Jave, un IDE es una herramienta esencial y le devolverá el dinero si aprende a usarlo bien (generación de código, fragmentos, refactorización). De hecho, hay muchas cosas que puede hacer con un IDE de Java que son simplemente imposibles de hacer con un IDE de Ruby o Python. Además, tiene los beneficios de un lenguaje tipado estático. Puede llevar más tiempo escribir, pero te ayuda a evitar errores comunes.

Ruby es mucho más divertido de usar. Hace que el desarrollador sea más feliz y productivo.

Lo mismo que arriba. En mi opinión, argumento altamente subjetivo.

Convención sobre configuración hace las cosas más rápido

Un marco de inyección de dependencia como Spring o Guice puede ayudar

Andamios, MVC ya está ahí para ti.

De nuevo, los frameworks Java MVC pueden ayudar

Bases de datos simplificadas Cargue elementos de la base de datos como objetos. Puede cambiar la base de datos sobre la marcha.

Hibernate, iBatis u otro marco ORM pueden ayudar. Con Hibernate Tools puede lograr una funcionalidad similar a la que tiene en RoR con archivos yml

Cargue nuevos módulos al instante

Maven o Ant Ivy pueden ayudar

Fácil implementación para probar

Su IDE o Jetty pueden ayudar. De hecho, la depuración es más fácil con Java

Pruebas integradas con el marco. El uso de objetos simulados facilita las pruebas

Un marco de inyección de dependencia puede ayudar con objetos simulados. JUnit fue un pionero de los marcos de unidades. No creo que Java sea menos fácil de probar.

Me gustaría saber cómo aborda la productividad aparentemente baja del desarrollo de aplicaciones web basadas en Java EE en comparación con otras pilas de tecnología ( Seaside , Ruby on Rails , etc.).

Las restricciones son:

La aplicación web terminada debe poder implementarse en contenedores de aplicaciones compatibles con Java EE
Si es posible, se debe preservar la inversión previa en una solución basada en Java, es decir, debe ser posible la interoperabilidad nativa con sistemas y bibliotecas basados en Java.
Debido a la estructura del equipo, se prefiere Java como lenguaje de implementación, aunque los lenguajes basados en JVM menos exóticos (es decir, Groovy) también podrían ser aceptables.
El sistema resultante debe ser arquitectónicamente sólido
El sistema resultante debe ser extensible y mantenible

Para no dejar que esto se reduzca a una discusión filosófica, solo me interesan las sugerencias que se basan en la experiencia práctica. Los posibles ejemplos incluyen lenguajes específicos de dominio, frameworks y MDSD.

Si apunta a una clase abstracta de soluciones (como MDA / MDSD), proporcione detalles sobre cómo lo implementó, así como información sobre las trampas comunes y las mejores prácticas.

Si no está de acuerdo con la suposición de que el desarrollo de aplicaciones web basado en Java EE implica una productividad inferior, me gustaría escuchar su razonamiento también.

EDITAR: Como hay muchas menos respuestas de las que esperaba, también aceptaré cuentas de intentos fallidos, básicamente ampliando la pregunta a "¿Cómo (no) mejorar la productividad al desarrollar aplicaciones web basadas en Java EE?".

Algunas reglas básicas:

Lanza el servidor de aplicaciones : una ENORME victoria y calidad. Mantenga un contenedor web si es necesario, pero configure todo en Spring y / o Hibernate para que el web.xml sea mínimo.
Pruebe todo, lo cual puede hacer ahora debido al paso 1 (no se necesitan XML de implementación ni generación de código: todo está configurado en el desarrollo).
Use Wicket para implementar su nivel web: ya nadie necesita JSP; Wicket es 10 veces más productivo y fácil de probar (vea el paso 2).
Utilice SCRUM y metodologías de desarrollo ágiles

El resultado es una productividad de Java tan alta como lo permiten los 4GL: en Atomikos tenemos varios proyectos de migración que nos gustaban así. Debido a que migramos desde las plataformas 4GL a Java / Java EE, pudimos comparar las estimaciones en ambos.

También vea esta publicación en el blog:

HTH

Chico

Bueno, no soy realmente un tipo Java, así que no puedo decir mucho, excepto por ... JSF

Intentamos usarlo durante un tiempo y fue un desastre. Todos los pasos básicos de Almots tuvieron que pasar con mucho dolor, sin documentación, sin ejemplos, sin conocimiento de la comunidad. Usamos entonces un plugin para Eclipse (Exadel Studio), echamos un vistazo a algunos otros frameworks JSF, todos eran incompatibles y estaban mal documentados. De hecho, de todos los que probamos, solo Sun framework (se olvidó de su nombre, basado en NetBeans) podría crear un nuevo proyecto JSF, incluso compilable de manera inmediata. El resto requirió muchos días de configuración de apache y otras cosas, lo que para una persona inexperta es un verdadero desafío (aunque lo logré).

Nuestro equipo pasó unos meses en algo que se hizo más tarde en unas pocas semanas con ASP.NET. La gente no tenía experiencia en JSF y ASP.NET.

Si el ecosistema de JSF sigue tan malo como lo fue en 2007, recomendaría evitarlo por completo, de todos modos la productividad está fuera de discusión. ¿Tal vez seguir con JSP o algo que está demostrado por el tiempo y bien desarrollado?

Creo que la pila ~~Java EE~~ Java es realmente muy buena. Hay algunas razones que explican la baja productividad de Java EE:

Al ser "la pila de la empresa", a menudo se usa para crear aplicaciones aburridas, "lo suficientemente buenas" y, en general, las empresas no suelen atraer a grandes desarrolladores que aman la programación y piensan y se preocupan por lo que hacen. La calidad del software en el mundo empresarial no es excelente.
Siendo el apilamiento de la empresa donde está el dinero, los proveedores de software intentan venderles algo. Crean soluciones enormes, complejas y caras, no porque sean buenas, sino simplemente porque podrían venderlas a las empresas.
Las empresas a menudo son muy reacias al riesgo y todo lo que hacen mejor es "estandarizar". Los estándares se crean después de que alguna tecnología demostró ser exitosa o anterior . En ambos casos, es malo para las empresas (y Java). Las empresas terminan usando una buena tecnología demasiado tarde o una tecnología totalmente fallada. Este último caso también es muy peligroso porque crea una falsa percepción de que una tecnología (de lo contrario, una falla completa) debe ser buena si está estandarizada y todos la usan.
Históricamente, la plataforma Java EE parecía haber atraído a una gran cantidad de arquitectos astronautas y desarrolladores de grandes compañías promovidos a arquitectos cuyo único propósito era crear más capas, más marcos, más abstracciones y más complejidad.

No es que no haya buenas herramientas y marcos de Java; es que hay demasiados malos, demasiados ingeniosos, demasiados procesos burocráticos y metodologías, demasiados estándares inútiles.

En un mundo tan desordenado, no es solo la selección particular de herramientas que elige lo que afecta su productividad. Se trata principalmente de usted, de sus valores, de cómo puede rechazar la mayoría de las soluciones que le propone la comunidad, los proveedores, los compañeros de trabajo y los gerentes. Se trata de ir contra la corriente, de su sentido común, de cuestionar todas las creencias principales y las "mejores prácticas".

Dicho esto, las herramientas por sí solas no van a cambiar mucho su productividad, y, a la inversa, las personas adecuadas también pueden ser productivas con herramientas inferiores.

Mi consejo:

No use una tecnología solo porque es estándar, porque todo el mundo lo usa o porque Sun lo recomienda oficialmente. Use una tecnología solo si usted personalmente considera que es la mejor herramienta para su trabajo. De esta manera, puede encontrarse rechazando tecnologías como JSF, JSP, servicios web, JMS, EJB, JTA, OSGi, MDA.
Mantenlo simple, usa tu sentido común, cuestiona todo. ¿Realmente necesita publicar sus objetos para acceso remoto? ¿Realmente necesita crear otra capa de abstracción para poder pasar de Hibernate a TopLink? ¿Realmente necesita convertir sus datos a / de XML diez veces cada vez que los necesite? ¿Realmente necesitas un esquema XML? ¿Realmente necesitas que todo para ser configurable sea intercambiable? ¿En tiempo de ejecución? Por no desarrolladores?
Mantenga el proceso simple. Sé agile . ¿Realmente necesitas esa documentación? ¿De verdad necesitas describir cada pantalla en una mesa enorme, tenerla aprobada, escribirla en alguna herramienta casera y luego generar JSP? ¿Tiene programadores competentes o diseña todo primero y los programadores solo "traducen" a Java?
El diseño WYSIWYG de HTML no funciona.
La programación gráfica en general no funciona. Esto incluye UML como blueprint y UML como lenguaje de programación , MDA, diagramas de flujo de página de dibujo. La generación de código es mala.
Nunca diseñe un marco antes de usarlo , siempre coseche un marco .
Prefiere marcos que tienen solo una pequeña configuración XML.
Esfuércese por un bajo recuento de LOC. Mira los personajes reales en tu código. ¿Es importante cada personaje? Pensar. ¿Qué puedes hacer para que tu código sea más pequeño? ¿Necesitas esa clase? ¿Qué hace? ¿Por qué necesitas hacer eso?
Las pruebas no son una vaca sagrada; no necesita una cobertura de prueba del 100%. Pruebe solo lo que tenga sentido. Si es difícil de probar, simplifíquelo; o no lo pruebes en absoluto. No pruebe la apariencia visual.

Y finalmente, algunas recomendaciones concretas de Java:

Para la capa de presentación prueba Tapestry . ¿Por qué me encanta? Porque con Tapestry puedes crear un hermoso código. Está diseñado específicamente para eso, por lo que su código puede ser hermoso . Tu código Por hermoso me refiero a todo lo que importa: es corto, fácil de cambiar, fácil de leer, fácil de crear, y aún flexible, no trata de ocultar el hecho de que usted está desarrollando para la web. Por supuesto, todavía eres tú quien hace que tu código sea hermoso.
Siéntase libre de usar Hibernate, especialmente para CRUD y aplicaciones grandes. No te molestes con JPA. Aunque no es una bala de plata, con ORM siempre vas a intercambiar una serie de problemas con otro.
Solo un poco de primavera, no debería necesitar mucho ya que ha evitado cuidadosamente todas las trampas Java EE. Use la inyección de dependencia con moderación.
Después de todo eso, puede encontrar que el lenguaje Java es demasiado detallado y no muy útil cuando abstrae el código de copiar / pegar. Si quieres experimentar, prueba Scala. El problema es que el principal punto de venta de Scala es que obtienes todos los beneficios de los lenguajes modernos sin dejar de mantener la seguridad del tipo, y al mismo tiempo, no hay un soporte IDE sólido . Siendo utilizado para super-cool IDEs de Java, no tiene mucho sentido cambiar a Scala a menos que haya un soporte IDE que sea estable y confiable. Lo suficientemente estable no es suficiente.

Definitivamente iría a la primavera junto con Hibernate para cosas relacionadas con la persistencia.

¿Por qué Spring?

La ventaja de utilizar Spring en lugar de otro framework es que la filosofía de Springs es ser " no invasiva ". Por lo general, cuando esté utilizando un marco de trabajo, probablemente comenzará a depender de ese marco, lo que puede ser un problema si se considera que la aplicación se ejecuta durante más tiempo, luego también debe hacer mantenimiento, etc. Spring utiliza el -llamado patrón de "Inversión de control" (IoC) . Básicamente tu código no (puede pero no tiene que) llamar a Spring, pero Spring te llamará (principio de Hollywood: "no me llames, te llamaré"). Entonces, por ejemplo, puede utilizar POJO normales (objetos Java antiguos simples) y no tiene que heredar de ninguna clase / interfaz relacionada con el marco. Otro gran problema (si no el más grande) en Ingeniería de Software son las dependencias. Lucharás por reducirlos tanto como sea posible ya que harán tu vida más difícil (especialmente en mantenimiento más adelante). Spring reduce drásticamente las dependencias entre sus componentes administrando la creación de instancias de componentes a través de archivos de configuración y el patrón de inyección de dependencia . No quisiera continuar, lo mejor es que comiences a leer algunos tutoriales en el sitio Spring oficial de Spring . Inicialmente puede necesitar algo de tiempo en el entendimiento, pero una vez que lo obtuvo, obtendrá muchos beneficios.

Desde Jython 2.5 puede usar django para satisfacer los requisitos que enumeró. Es bastante fácil generar archivos war desde proyectos django y desplegarlos en servidores de aplicaciones J2EE.

He usado Jboss Seam en los últimos años y considero que es una forma muy productiva de desarrollar en Java EE (utilizando EJB3, Hibernate, Facelets). También hago un poco de codificación PHP en el lado y puedo decir honestamente que soy más productivo con Seam (aunque eso también es probablemente una indicación de mis habilidades PHP).

Para mí, algunos de los aspectos más destacados serían:

Implementación en caliente del código (un absoluto imprescindible)
SECO con Facelets
Configuración basada en anotaciones
Extensos componentes integrados (especialmente ajax4jsf)
Soporte IDE de Jboss Tools

Hay herramientas en el IDE y en la línea de comandos para construir código de esqueleto de forma similar a RoR.

Los marcos como Spring , Hibernate , Wicket sin duda ayudan a simplificar y acelerar el desarrollo web, ya que proporcionan un alto grado de capacidad de prueba e integran muy bien. Pero no es suficiente para alcanzar la productividad de RoR, incluso si tiene un buen conjunto de prácticas de desarrollo. Todavía hay demasiadas cosas técnicas y se requiere plomería.

Grails es quizás la pieza que falta en esta imagen para acercarse a RoR. Es mi próximo experimento.

Por cierto, mis experiencias de MDA son lo contrario de una mejora en la productividad, así que no las mencionaré (en realidad, la MDA estaba acabando con nuestra productividad).

Me gustaría ir con el marco Lift escrito en Scala. Verá un gran aumento de productividad simplemente al cambiar a Scala . Scala también es muy estable y es extremadamente fácil llamar al código Java desde su código Scala. No solo eso, sino que es bastante similar a Java pero con algunas características adicionales. Para algunos ejemplos, debe consultar 5 Cosas que un desarrollador de Java necesita saber sobre Scala. Twitter transferirá parte de su código base a Scala.

Nunca se "atascará" en un fragmento de código porque solo puede pensar en cómo lo haría en Java y escribir un código similar. Las funciones y los actores de primera clase le darán un impulso de productividad aún mayor y ambos se encuentran en Scala. Por supuesto, Scala está tipado estáticamente y tiene un rendimiento similar al de Java.

Citaré al autor del Lift Framework para una descripción de esto:

Levante los préstamos de los mejores marcos existentes, proporcionando
Sesiones altamente detalladas de Seaside y rieles de seguridad rápidos flash-to-bang
Django "más que solo CRUD está incluido"
Estilo de creación de plantillas amigable con el diseñador de Wicket (vea la Vista de Ascensor
Primero)
Y debido a que las aplicaciones Lift están escritas en Scala, un nuevo y elegante lenguaje JVM, aún puede usar sus bibliotecas Java favoritas e implementarlas en su Servlet Container favorito. ¡Usa el código que ya has escrito y despliégalo en el contenedor que ya has configurado!

Solo quería lanzar otra idea ... en realidad puedes usar JRuby y Rails (similar al comentario anterior sobre Django y Jython).

Si usa JRuby con Rails y JRuby Rack (y tal vez algunas otras utilidades ... Yo no fui el que inicialmente se encargó de la integración), puede implementar adiciones de JRuby Rails a una aplicación web Java existente. Tenemos una aplicación JSP heredada implementada con Tomcat, y ahora estamos empezando a agregar nuevas páginas usando Rails con solo esa configuración (además de extender el lado JSP cuando sea necesario). Hasta ahora ha sido bastante exitoso, aunque no tenemos ninguna de las principales páginas de alto tráfico implementadas en Rails, así que no sé qué tan bien se escalará.

Tenemos acceso completo a la sesión, e incluso hemos configurado mecanismos para invocar JSP desde las páginas de Rails (como el encabezado existente y el tipo de pie de página que incluye JSP). Lleva un poco de esfuerzo y prueba y error integrar completamente el 2, pero si Rails y JRuby son una opción, lo recomiendo encarecidamente (como fanático personal de Ruby).

Un colega se ha metido en JBoss Seam, que es un framework de Gavin King (el chico que nos trajo a Hibernate), que estaba destinado a emular a Rails. Habiendo visto ambas cosas, creo que Rails es mucho más fácil de desarrollar.

Un punto importante al analizar la productividad de Java EE: debe utilizar Java EE 5 y EJB3.x ya que proporcionan un nuevo nivel de productividad (y funcionalidad) en comparación con versiones anteriores.

Mantenerse dentro de las especificaciones estándar de Java EE es absolutamente importante, por ejemplo, usar Hibernate en lugar de JPA no es beneficioso para la productividad. No hay ninguna limitación para recurrir a las funciones de Hibernate cuando se utiliza JPA, pero al utilizar Hibernate en lugar de JPA, se bloquea en un único proveedor de persistencia sin una salida económica. Toda la idea detrás de usar estándares es la misma: flexibilidad conceptual (al conectar en diferentes implementaciones) con extensibilidad disponible (mediante el uso de extensiones propietarias si es absolutamente necesario). Java EE 5 y EJB3 son pasos enormes en esta dirección. Por supuesto, desea minimizar las características de propiedad, pero si algunas parecen absolutamente necesarias, es una buena señal de que formarán parte de las especificaciones en la próxima versión ...

Los principales obstáculos para la productividad de Java EE se encuentran en su enfoque empresarial (ofrece mucho más de lo que se necesita para la mayoría de los proyectos) y en su legado (compatibilidad con versiones anteriores). También hay mucho más por hacer en el nivel de presentación con JSF y la administración estatal: observe el JSR-299 para abordar estas, entre otras mejoras.

Use AOP (Programación Orientada a Aspectos) para aspectos transversales como el registro, la autorización, etc. Puede usar Spring AOP o AspectJ. Hace el desorden de código libre y mantenible.

Grails es un framework webapp de Java muy modelado después de Ruby on Rails, con principios similares (DRY, CoC) y ganancias de productividad, pero basado en frameworks Java existentes (Spring, Hibernate, varios otros).

He estado trabajando en un proyecto exploratorio usando Grails durante unas semanas (sin experiencia previa en Grails o Groovy), y estoy bastante impresionado. Hay algunas asperezas: no es tan maduro como RoR, pero puede obtener resultados rápidamente y nunca siente que el marco se interponga en su camino.

Tal vez se ilustra mejor con este ejemplo concreto: quise editar una matriz 2D de objetos de dominio en una cuadrícula en una sola página web y encontré que la asignación automática de los datos de solicitud HTML a los objetos de dominio (proporcionados por Spring MVC, creo ) tenía un error que causaba que algunos datos se asignaran a los objetos incorrectos. Miré alrededor de la red durante una hora, pero aparentemente nadie había encontrado o resuelto el problema. Eventualmente decidí renunciar al mapeo automático y hacerlo "manualmente", y luego descubrí que no me llevaba más de 10 líneas de código ...

Javarebel puede reducir en gran medida el tiempo empleado durante el desarrollo web utilizando Java.

Permítanme citar aquí el sitio web oficial:

JavaRebel es un complemento de JVM (-javaagent) que le permite ver cambios en su código de inmediato, sin la necesidad de volver a desplegar una aplicación o reiniciar el contenedor. Si estás cansado de ver los registros y quieres ver los cambios para que puedas continuar, JavaRebel es tu nuevo mejor amigo.