java - Objetos desnudos. Bueno o malo

frameworks naked-objects (10)

Gareth hace algunos puntos excelentes.

Hay otros problemas, como el hecho de que es difícil controlar la apariencia, y son contraintuitivos para las personas que se han acostumbrado al modelo de ventana. También hay algo de un problema de modelado, ya que no todos los dominios de aplicación se prestan bien para dirigir la representación de objeto.

El modelo general de "programador ciudadano", como se propugna en las comunidades de objetos pequeños y de objetos desnudos, también tiene una idea cuestionable. La mayoría de los usuarios no parecen estar muy molestos con cambiar la funcionalidad ellos mismos, por lo que pensar en objetos no es tan útil.

Recientemente he estado expuesto a objetos desnudos. Parece un marco bastante decente. Sin embargo, no lo veo en un uso generalizado, como por ejemplo, Spring. Entonces, ¿por qué este marco no obtiene ningún crédito de aplicación convencional? ¿Cuáles son sus defectos como ves?

Jugué con él el año pasado y concluí que es muy fácil trabajar con él.

La fuerza de Naked Objectsis es que obtienes una GUI estructurada de acuerdo con tu modelo de datos de forma gratuita. La desventaja es que un usuario típico no piensa en su proceso como una colección de registros.

Mi conclusión fue que Naked Objects es realmente ideal para una aplicación interna que trata conceptualmente los registros, como una aplicación de inventario o una aplicación de procesamiento de facturas.

Si necesita algo diferente, adaptar el marco a sus deseos puede ser mucho más trabajo que usar un marco escrito para soportar el tipo de aplicación que desea.

Por cierto, hay una opción de renderizado web; ver la demostración en la demostración de Naked Objects .

Se ha utilizado con éxito aquí en Irlanda .

Creo que las razones por las que no ha sido más popular son:

Necesita mucha confianza en los kits de herramientas que está utilizando
Hace que la GUI sea un factor de riesgo en lugar de una obviedad (tanto técnicamente como en las pruebas de usabilidad)
No es aplicable a la web (hasta donde yo sé), que es donde la mayor parte del foco está presente ...

Probablemente la razón por la que no ha recibido más atención es porque el mundo J2EE se ha acostumbrado a acumular tantas capas en una aplicación, que los objetos desnudos resultan ingenuos.

¿Dónde están nuestros servicios? ¿Quiere decir que cualquier objeto desnudo me da acceso inmediato a la base de datos? ¿Qué pasa si necesitamos exponer la aplicación con llamadas RMI?

Además, no hay tanto en el mercado, porque pone la carga de desarrollar una aplicación exitosa directamente en los desarrolladores de aplicaciones, no en los desarrolladores de frameworks :)

De mi experiencia usando NOF 3.0.3 ...

El bueno:

Automáticamente genera una interfaz de usuario DnD para sus objetos de dominio, como lo que hace db4o para la persistencia.
Esto es lo que MVC siempre debe ser, según el creador de patrones MVC.
El marco solo le pide a sus objetos de dominio (POJO) que se subclases de AbstractDomainObject, que es todo el cableado mínimo.
El marco favorece la configuración OVER de la convención: muchas anotaciones sin configuraciones gmail enloquecidas.
Funciona muy bien para la creación de prototipos junto con db4o para la persistencia.
Funcionalidad lista para usar para Hibernate.
En mi caso, solicité como 30 minutos desde la aplicación Download to Hello world. (IntelliJ IDEA IDE)
Implementación como JNLP, independiente, web (Jetty incrustado o sabor Scimpi) y Eclipse RCP.
El equipo de NOF SIEMPRE está a su disposición cuando solicita ayuda en los foros.
El patrón de objetos desnudos es una idea increíble, hazte un favor y tómate tu tiempo para asimilarlo.
Hay mucha llamarada de usabilidad alrededor de la GUI de Arrastrar y soltar, pero si tus posibles usuarios finales simplemente no pueden trabajar con la interfaz de usuario de DnD, de todos modos estás en un gran problema.

El malo:

Ninguno que yo pueda pensar

Un poco feo

No se permiten componentes Swing, así que díganse adiós a JGoodies y a todos sus conjuntos de componentes Swing favoritos. Los componentes de la interfaz de usuario están hechos a medida; para hacerte una idea, se ven como los primeros controles de VB de los 90''s. Pero hay un puerto SWT en proceso.
El campo de línea multilínea para cadenas largas tiene algunos problemas. (NOF 3.0.3)
La interfaz de usuario de DnD para imágenes es un poco falsa.
El código de validación para getters n setters solo se activa si el objeto de dominio se modifica desde la UI. (Esto probablemente sea incorrecto debido a mi n00bness, esperemos que un committer NOF me corrija)
Si un objeto se modifica a partir de un hilo que no es ui, digamos un trabajador bg, tal objeto
no actualiza su vista en la pantalla. Esto invalida un caso de uso como representar una cola de correo en tiempo real en la interfaz de usuario autogenerada de DnD. (De nuevo)
Veikko

Solo acabo de ver esto. Un par de correcciones menores, de lo contrario la mayoría de los comentarios son muy justos.

1) ''El marco solo pide que los objetos de tu dominio (POJO) se subclases de AbstractDomainObject, eso es todo el cableado mínimo.''

Naked Objects no requiere que los objetos de dominio se subclases de AbstractDomainObject, aunque eso suele ser lo más conveniente.

Si no desea heredar, todo lo que necesita hacer es proporcionar una propiedad de tipo IDomainObjectContainer, y la infraestructura inyectará un contenedor en sus objetos cuando se creen o recuperen. El contenedor tiene métodos para Resolve (), ObjectChanged () y NewTransientInstance (), que son los tres puntos de contacto minimalistas con el marco que debe usar, para que el marco permanezca sincronizado con los objetos de su dominio.

2) ''Funciona muy bien para la creación de prototipos junto con db4o para la persistencia''. Estamos muy entusiasmados con la idea de trabajar con db4o, pero no conozco a nadie que haya hecho que Naked Objects y db4o jueguen juntos. Si alguien ha hecho esto, me gustaría saber más al respecto.

3) ''El modelo general de programador citzen como propugnado en el smalltalk y las comunidades de objetos desnudos ...''. Nunca hemos defendido esa idea y no estoy de acuerdo con ella. Naked Objects NO se trata de alentar a los usuarios a programar. Creo firmemente en el papel del desarrollador profesional: Naked Objects simplemente les ayuda a escribir un mejor software y de forma más productiva.

Ricardo

Supongo que NakedObject definitivamente tiene su relevancia y es más que tiempo que la comunidad de desarrolladores se reenfoque en lo que realmente les está pagando: el negocio. En cambio, pasamos nuestro tiempo principalmente con infraestructura, protocolos y toda esa basura técnica. He visto aplicaciones construidas como tales e incluso hice algunas siguiendo la corriente principal, enseñándole que aplicar capas a un sistema siempre es algo bueno. Lo peor es que si le pregunta a algunos desarrolladores sobre qué tipo de negocio hace la empresa para la que trabajan, encontrará al menos a algunos que trabajaron para la empresa durante años sin obtener una comprensión más profunda del negocio. Sin embargo, no creo que NakedObject atraiga a la gran mayoría de los desarrolladores (incluso aquellos que están inspirados en DomainDrivenDevelopment) simplemente porque la gente adora construir UI y quitarle ese trabajo, dirigiendo su trabajo hacia las necesidades de las empresas, simplemente no es lo que quieren: todos somos idiotas de VB.

NakedObjects (NO) son buenos para el prototipado rápido. Puede concentrarse en el Modelo de Dominio sin prestar atención a GUI, DB y otras partes de su solución. Para la producción, requiere muchas mejoras (corrección de errores, mapeo de datos, interfaz gráfica de usuario, etc.) en el propio marco NakedObjects.

Entonces, si necesita obtener algún tipo de "prueba de concepto" para su solución, puede usar NO. Pero para la producción, prepárese para invertir recursos en el desarrollo del marco NO.

Por cierto, recientemente estamos trabajando en la creación de visor DnD basado en GWT para NO 4.0.

el uso generalizado de la tecnología no tiene una fuerte correlación con la calidad tecnológica.
El sistema nakedobject es difícil de usar en combinación con objetos tipo: si estoy vendiendo diferentes tipos de productos y necesito diferentes datos para diferentes productos, es difícil restringir los datos en el tipo de producto.
NO perdió impulso cuando cambiaron las licencias. (a GPL + Comercial, no el movimiento reciente a Apache)

¿Echaste un vistazo a jmatter?

[edit] Y otro: hace que sea obvio para los no programadores si puedes cumplir. Spring está en el dominio tecnológico, NO significa que un desarrollador tiene que hablar con los usuarios. Las grandes organizaciones no hacen eso.

He estado trabajando en el enfoque de objetos desnudos durante más de un año y ni siquiera he empezado a arañar la superficie de las posibilidades que ofrece para la arquitectura de su sistema. Sin embargo, para utilizarlo correctamente, se requiere crear un cambio de paradigma y buscar soluciones OO completas y revertir el recurso a cintas de pato funcionales, ya que el paradigma parece funcionar solo cuando se crea un diseño que permita el desarrollo de alto nivel.

Habiendo dicho eso, me encanta cómo Django ha implementado objetos desnudos dentro de sus modelos Django. La mayoría de las cosas que me encantan sobre el framework han sido, lo que llego a creer, un resultado directo de sus modelos y hay algunos wows fuera de la cima que me gustaría compartir sobre la arquitectura:

Los campos de modelo, que se asignan a columnas de tabla, son objetos completos de comportamiento: saben cómo se representan tanto en la aplicación como en el dominio de la base de datos, cómo se convierten entre los dos y cómo se valida y muestra la información que contienen. usuario visualmente para las entradas. Todo esto utilizado con una sola línea de código en su modelo. ¡ Guau !

Los administradores se adjuntan a los modelos y proporcionan CRUD y cualquier operación genérica en las colecciones, como consultas reutilizables (darme las últimas cinco publicaciones del blog, la mayoría de las etiquetas que se producen, etc.), operaciones de eliminación masiva / y lógica de negocios realizada en instancias. ¡ Guau !

Ahora considere que tiene un modelo que representa a un usuario. A veces, solo desea obtener una vista parcial de toda la información que contiene un modelo de usuario (al restablecer la contraseña de un usuario, es posible que solo necesite el correo electrónico del usuario y su pregunta secreta). Han proporcionado una API de formularios que muestra y administra las entradas para solo partes de los datos del modelo. Permite cualquier personalización del qué / cómo al manejar la entrada del usuario. ¡ Guau !

El resultado final es que sus modelos solo se utilizan para describir qué información utiliza para describir un dominio en particular; los gerentes realizan todas las operaciones en los modelos; los formularios se utilizan para crear vistas y para manejar las entradas del usuario; los controladores (vistas) solo están ahí para manejar verbos HTTP y si funcionan con modelos es únicamente a través de gerentes y formularios; Las vistas (plantillas) están ahí para la presentación (la parte que no se puede generar automáticamente). Esto, imho, es una arquitectura muy limpia. Diferentes administradores pueden ser utilizados y reutilizados en diferentes modelos, se pueden crear diferentes formularios para los modelos, diferentes vistas pueden usar diferentes administradores. Estos grados de separación le permiten diseñar rápidamente su aplicación.

Usted crea un ecosistema de objetos inteligentes y obtiene una aplicación completa de la forma en que están interconectados. Con la premisa de que están vagamente acoplados (muchas posibilidades para que se comuniquen de diferentes maneras) y pueden modificarse y ampliarse fácilmente (unas pocas líneas para ese requisito en particular), siguiendo el paradigma, realmente se obtiene una arquitectura en la que componente escribe una vez y luego vuelve a utilizarlo en tus otros proyectos. Es lo que MVC debería haber sido siempre, sin embargo, a menudo he tenido que escribir algo desde cero, aunque hice lo mismo hace algunos proyectos.