¿Cuántas entidades debe incluir el servicio de dominio RIA?

Question

Me preguntaba cómo implementar exactamente el servicio de dominio en RIA. ¿Es común incluir todas las entidades en el modelo de dominio completo en un solo servicio de dominio, haciendo que el servicio sea responsable de toda la base de datos? ¿Es esta la manera en que normalmente se hace? Realmente no tengo ninguna razón para separar el acceso a datos en diferentes servicios, pero me preguntaba si esto se considera una buena práctica, y cuáles serían los pros y los contras de tal enfoque.

Además, ¿se considera una buena o mala práctica registrar el contexto del dominio como singleton con IOC, de modo que toda la aplicación funcione con el mismo conjunto de datos, evitando problemas de concurrencia y problemas similares?

¿Pensamientos?

Gracias

Answer 1

Tenemos dos servicios por separado en nuestra aplicación: una para el modelo de datos y se utiliza estrictamente para la autenticación. Tomamos este diseño de la estructura de la aplicación de muestra comercial de MS.

Consideramos dividir nuestro servicio de dominio de datos en componentes más pequeños, pero decidimos no hacerlo porque no parecía agregar ninguna ventaja (aparte de reducir el tamaño de la clase de servicio). Si tiene modelos de datos distintos e independientes de cada uno otro entonces ir por esa ruta puede tener sentido. Intuitivamente, el servicio de dominio debe representar todo el dominio. Si sus dominios son independientes (con el occasional need for crossover), tiene sentido lógico segregarlos de esa manera.

En cuanto a usar el contexto como Singleton: lo intenté y terminé creando instancias de ámbito de clases en su lugar. No hemos tenido problemas al hacerlo de esta manera, ya que todos usan la misma conexión de datos subyacente. No sé cuál es la mejor práctica "oficial", pero esta es la forma en que lo he visto en numerosas aplicaciones de RIA.

Answer 2

Gracias Nick. De hecho, hice lo mismo que tú. Creé dos servicios, uno para autenticación y otro para acceso a datos. Eso me parece lo más lógico.

En cuanto a hacer de datacontext un singleton, lo he intentado también y funciona muy bien. No es necesario volver a cargar y actualizar datos constantemente y preocuparse por problemas de simultaneidad en otras clases :)