Objetos desnudos. Bueno o malo

Question

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?

Answer 1

A partir de mi experiencia en el uso NOF 3.0.3 ...

Lo bueno:

• genera automágicamente una interfaz de usuario NOM para sus objetos de dominio, al igual que lo hace db4o para la persistencia.
• Esto es lo que MVC debía ser siempre, según el creador de patrones MVC.
• El marco de trabajo 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 configuración XML freaking.
• Funciona muy bien para el prototipado junto con db4o para la persistencia.
• Funcionalidad fuera de la caja para Hibernate.
• En mi caso, solicité como 30 minutos desde la aplicación Hello Hello para descargar. (IntelliJ IDEA IDE)
• Despliegue como JNLP, independiente, web (incrustado Jetty o sabor Scimpi NOX) y Eclipse RCP.
• El equipo de NOF está SIEMPRE a su disposición cuando solicita ayuda en los foros.
• El patrón de objetos desnudos es una idea impresionante, hazte un favor y tómate tu tiempo para asimilarlo.
• Hay una gran cantidad de usabilidad en llamas en los alrededores del arrastrar y soltar interfaz gráfica de usuario, pero si sus usuarios finales potenciales simplemente no pueden trabajo con la interfaz de usuario DnD entonces usted está en serios problemas de todos modos.

Lo malo:

• Ninguno que se me ocurre.

El poco feo:

• No se admiten los componentes Swing, por lo que decir adiós a JGoodies y todos sus conjuntos de componentes Swing de 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 problemática.
• El código de validación para getters n setters solo se activa si el objeto de dominio se modifica desde la interfaz de usuario. (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 de la interfaz de usuario, digamos un b.g. trabajador, dicho 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. (Una vez más)

• Veikko

Answer 2

Se ha utilizado satisfactoriamente here in Ireland.

creo razones por las que ya no haya sido más populares son:

• se necesita un montón de confianza en los kits de herramientas que está utilizando
• Esto hace que la interfaz gráfica de usuario de un factor de riesgo en lugar de una obviedad (tanto técnicamente como en las pruebas de usabilidad)
• no es aplicable a la web (por lo que yo sé), que es donde la mayor parte de la atención se centra tan presente ...

Answer 3

Gareth hace algunos puntos excelentes.

Existen 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 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.

Answer 4

He jugado con él el año pasado más o menos, y concluyó que es muy fácil trabajar con él.

La fuerza de Naked Objectsis es que obtiene una GUI estructurada de acuerdo con su 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 genial para una aplicación interna que conceptualmente trata con 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 representación web; vea la demostración al Naked Objects Demo.

Answer 5

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 es tanto al mercado, ya que pone la carga de desarrollar una aplicación exitosa de lleno en los desarrolladores de aplicaciones no los desarrolladores marco :)

Answer 6

sólo he visto esto. Un par de correcciones menores, de lo contrario la mayoría de los comentarios son muy justos.

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

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

Si no desea heredar, todo lo que necesita hacer es proporcionar una propiedad de tipo ID dominioObjectContainer, 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 el prototipado 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 las comunidades de smalltalk y objeto desnudo ...'. 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.

Richard

Answer 7

• uso generalizado de la tecnología no tiene 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 sobre el tipo de producto.
• NO perdieron impulso cuando cambiaron las licencias. (para GPL + Comercial, no el movimiento reciente a Apache)

¿Echa un vistazo a jmatter?

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

Answer 8

Supongo que NakedObject definitivamente tiene su relevancia y es más que el tiempo que la comunidad de desarrolladores se centra de nuevo en lo que realmente les está pagando: el negocio. En su lugar, 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, es simplemente no es lo que quieren: todos somos idiotas de VB.

Answer 9

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.

Por lo tanto, 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.

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

Answer 10

He estado trabajando en el enfoque de los objetos desnudos desde hace 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 llegué a creer, un resultado directo de sus modelos y hay algunos wows fuera de la cima que me gustaría compartir sobre la arquitectura:

Campos de modelos, eso asignar 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 la información que guardan se valida y se muestra visualmente al usuario para las entradas . Todo esto utilizado con una sola línea de código en su modelo. Wow!

Los gerentes se adjuntan a los modelos y proporcionan CRUD y cualquier operación genérica en las colecciones, como consultas reutilizables (dame las últimas cinco publicaciones del blog, etiquetas más frecuentes, etc.), operaciones de eliminación masiva \ actualización y lógica de negocios en instancias. Wow!

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. Wow!

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.

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 extenderse 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.