cref - remarks c#
¿Cuántas entidades debe incluir el servicio de dominio RIA? (2)
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 de 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
Tenemos dos servicios separados en nuestra aplicación: uno para el modelo de datos y uno estrictamente utilizado 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 que son completamente independientes uno del otro, entonces eso significa ruta puede tener sentido. Intuitivamente, el servicio de dominio debe representar todo el dominio. Si sus dominios son independientes (con la necesidad ocasional de cruce ), tiene sentido lógico segregarlos de esa manera.
En cuanto a usar el contexto como Singleton: lo intenté y terminé creando instancias de alcance de clase 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.
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 que datacontext sea singleton, lo he intentado también y funciona muy bien. No hay necesidad de volver a cargar y actualizar datos constantemente y preocuparse por problemas de concurrencia en otras clases :)