¿Cuánta lógica de negocios pertenece a la capa de servicios de RIA?

Question

He estado experimentando recientemente con Silverlight, RIA Services y Entity Framework usando .NET 4.0. Estoy tratando de averiguar si esa pila tiene sentido para usar en cualquiera de mis próximos proyectos. Ciertamente parece que estas tecnologías pueden ser muy productivas para el desarrollo de aplicaciones, pero estoy luchando por decidir cómo se debe diseñar una aplicación sobre esta pila.

El problema principal que tengo es que en la mayoría de las demos que he visto, la mayor parte de la lógica de negocios termina en anotaciones de datos y validaciones personalizadas en la clase de servicio de dominio de servicios de RIA. Esto me parece inapropiado. Veo el servicio de dominio básicamente como un servicio web glorificado que hace que sea fácil enviar información al cliente. Pero la mayoría de lo que he visto parece orientar el servicio de dominio como la principal fuente de lógica de negocios en la aplicación.

lo tanto, mi pregunta:

• ¿Cuál es la mejor ubicación para la lógica de negocio (reglas, validaciones, comportamientos, autorización) en una aplicación que utiliza esta pila?
• ¿Hay alguna guía publicada a nivel arquitectónico para usar esta pila?

Mis preguntas se refieren a aplicaciones grandes, complejas y de larga duración. Obviamente, para una aplicación de solo unas pocas pantallas esto es menos preocupante.

Editar: Otra cosa que quería mencionar es que, obviamente, se puede hacer la clase de servicio de dominio estúpida, pero entonces se pierde una gran parte de la información de la entidad (por ejemplo automagic validaciones) siendo empujado al cliente. Y luego, si pierde eso, ¿hay algún punto para usar los servicios de RIA?

Answer 1

Nuestro equipo está en el proceso de implementar una aplicación Silverlight en la parte superior de la pila de RIA. Hemos decidido construir un modelo de dominio sobre las entidades de RIA. Además, elegimos seguir el patrón MVVM para modelar las interacciones de UI.

Hasta ahora, me he dado cuenta de los siguientes beneficios:

1. clases de dominio son un buen lugar para poner la lógica de negocio incluyendo validaciones complejas.
2. Las clases de dominio usan las entidades RIA y el contexto como interfaz para el almacén de datos.
3. Las clases de dominio se modelan después de las preocupaciones comerciales y no requieren una relación uno-a-uno con las entidades de RIA.
4. Las validaciones de IU simples pueden vivir en ViewModels.

Otra cosa a tener en cuenta es que hemos implementado nuestro propio mapa de identidad para la simultaneidad y empujado el seguimiento sucio al contexto de RIA.

En la práctica, esta arquitectura requiere un poco más de esfuerzo de codificación, pero paga mucho tiempo con legibilidad y facilidad de mantenimiento. Incluso para aplicaciones CRUD simples, seguiría esta práctica. Tener la capacidad de crear un modelo de dominio que represente con más precisión el espacio problemático es una ventaja convincente.

Answer 2

En general, es más productivo trabajar con la tecnología que en contra de ella.

Como dice la lógica de negocios termina en DataAnnotations y validaciones personalizadas, este puede ser el "mejor" lugar para la productividad del desarrollador, para la primera versión del sistema.

Tengo la sensación de que esta tecnología tiene su fuerza para crear rápidamente aplicaciones crud, cuando tiene una lógica de negocios complicada puede terminar con una capa de negocios adicional entre la aplicación Silverlight y los servicios RIA.

No hemos intentado construir algo real en esto todavía, solo sabremos realmente la respuesta a esto después de haberlo usado durante algún tiempo.