Ayudar w/ DDD, SOA y PI

Question

Sin entrar en todos los detalles escabrosos, estoy tratando de diseñar un servicio basado en la solución que va a ser consumido por varias aplicaciones cliente.La solución permite a los administradores crear y modificar plantillas de documento que son utilizados por los usuarios regulares para realizar la entrada de datos.Es mi intención de hacer la aplicación de una herramienta de aprendizaje de las mejores prácticas, técnicas, etc.

Y, al mismo tiempo, tengo que acomodar un esquizofrénico medio ambiente, debido a los 'poderes fácticos' no siempre se adhieren a sus decisiones respecto a las tecnologías y herramientas.Por ejemplo, estoy usando Linq to SQL hoy, porque no están listos para ir a EF4 pero hay también una discusión sobre el cambio de NHibernate.Así que, tengo que hacer el código como la persistencia de ignorantes como sea posible para minimizar el trabajo requerido, debemos cambiar de O/M de herramientas.

En este punto, también estoy limitado a la utilización de la clase parcial enfoque para ampliar la Linq to SQL a las clases que implementan las interfaces definidas en mi capa de negocio.No puedo ir con POCOs porque la gerencia insiste en que debemos aprovechar todos los integrados en herramientas, etc.así que debe soportar el Linq to SQL designer.

Dicho esto, mi interfaz de servicio tiene un StartSession método que acepta un identificador de plantilla en su firma.La operación fluye como este:

1. Si ya existe una sesión en la base de datos para el usuario actual y la plantilla especificada, actualizar el registro para mostrar la actividad actual.Si no, crear un nuevo objeto de la sesión.
    
2. La sesión está asociado con una instancia de la plantilla, lo llaman el "formulario".Así que si la sesión es nueva, necesito recuperar la información de la plantilla para crear la nueva "forma", asociado con la sesión, a continuación, guardar la sesión para la base de datos.Por otro lado, si la sesión ya existía, entonces tengo que cargar el formulario con los datos introducidos por el usuario y almacenada en la sesión previamente.
    
3. Finalmente, en la sesión (con la definición de formulario y datos) se devuelve al llamador.
    

Mi primer objetivo es crear separación entre la lógica de las capas de mi aplicación.El segundo es mantener la persistencia de la ignorancia (como se mencionó anteriormente).Tercero, tengo que ser capaz de probar de todo, así que todas las dependencias deben ser externalizados fácil de burla.Estoy usando la Unidad como un Cio herramienta para ayudar en esta área.

Para lograr esto, he definido mi clase de servicio y contratos de datos según sea necesario para apoyar a la interfaz de servicio.La clase de servicio tendrá una dependencia inyectado desde la capa de negocio que realmente realiza el trabajo.Y aquí es donde se ha metido desordenado para mí.

He sido intentar ir a la Unidad de Trabajo y el Repositorio de ruta para ayudar con la persistencia de la ignorancia.Tengo una ITemplateRepository y un ISessionRepository que puedo acceder desde mi IUnitOfWork aplicación.La clase de servicio se presenta un ejemplo de mi SessionManager clase (en mi BLL) inyectado.El SessionManager recibe el IUnitOfWork la aplicación a través de la inyección de constructor y delegar la totalidad de persistencia para el UoW pero me encuentro jugando un juego de la cáscara con los diversos lógica.

En caso de que la lógica descrita anteriormente en el SessionManager clase o tal vez la UoW aplicación?Quiero tan poco lógica como sea posible en el repositorio de implementaciones porque el cambio de la plataforma de acceso a datos podría resultar en cambios no deseados a la lógica de la aplicación.Desde mi repositorio está trabajando en contra de una interfaz, ¿cómo puedo hacer mejor ir sobre la creación de un nuevo período de sesiones (teniendo en cuenta que una sesión válida tiene una referencia a la plantilla, er, la forma de ser usado)?Sería mejor utilizar POCOs aunque tengo que apoyar el diseñador y el uso de una herramienta como AutoMapper dentro del repositorio de la aplicación para gestionar la traducción de los objetos?

Ugh!

Yo sé que estoy atascado en la parálisis por análisis por lo que un poco de empuje es probablemente todo lo que necesito.¿Qué sería lo ideal sería que si alguien puede proporcionar un ejemplo de cómo se podría resolver el problema debido a las reglas de negocio y restricciones arquitectónicas he definido.

Answer 1

Si no utilizar POCOs, a continuación, su realidad, no va a ser almacén de datos agnóstico.Y el uso de POCOs le permitirá obtener de su sistema y se ejecuta con la memoria de los repositorios que es lo que es probable que desee utilizar para la unidad de pruebas, de todos modos.

El AutoMapper suena bonito pero no me considero un interruptor.La asignación de POCOs a EF4, LinqToSql, nHibernate no es que mucho tiempo a menos que usted tiene cientos de mesas.Cuando/Si sus POCOs comienzan a divergir de su capa de persistencia, a continuación, usted podría encontrar que un AutoMapper realmente no lo se ajustan a la ley.