patrón de repositorio con una base de datos heredada y Linq to SQL

Question

Estoy creando una aplicación sobre una base de datos heredada (que no puedo cambiar). Estoy usando Linq to SQL para el acceso a datos, lo que significa que tengo una clase (Linq to SQL) para cada tabla.

Mi modelo de dominio no coincide con la base de datos. Por ejemplo, hay dos tablas llamadas Usuarios y Empleados , y por lo tanto tengo dos clases de Linq a SQL llamadas Usuario y Empleado . Pero en mi modelo de dominio me gustaría tener una clase User que debería contener algunos campos de cualquier tabla (pero no me importan muchos de los otros campos de estas tablas).

No estoy seguro de cómo debo diseñar mis repositorios:

• si los repositorios realizan la asignación entre las clases de Linq a SQL (por ejemplo, Usuario , Empleado ) a las clases de dominio ( Usuario ) y solo devolver las clases de dominio a la aplicación
• o si mis repositorios devuelven las clases Linq a SQL y dejan la asignación a la persona que llama

El primer enfoque parece tener más sentido para mí, pero ¿es esta la forma correcta de implementar mis repositorios?

Answer 1

El purista (trato de mantenerme puro) le dirá que su modelo representa sus datos. Y por lo tanto, cualquier cosa que deba persistirse se hace solo cuando sea necesario a través de repositorios. Además, cuando tiene entidades complejas, desea utilizar un servicio para combinarlas. Por ejemplo, User + Employee = UserEmployee entidad a la que solo se puede acceder a través de un IUserEmployeeService.

Con esas declaraciones vagas, tiene una excelente oportunidad aquí.

Cree una capa anticorrupción que le permita comenzar a salir de la base de datos heredada al mismo tiempo.

Este es otro capítulo en el libro de jugadas DDD. Se usa una capa anticorrupción para interactuar con un sistema heredado que usa fachadas, traductores y adaptadores para aislar la base de datos heredada con su modelo de dominio puro.

Ahora, esto puede ser mucho más trabajo del que querías. Entonces, debes preguntarte en este punto:

  

¿Quiero comenzar el proceso de   alejándose de esta base de datos heredada, o lo hará   permanece para la vida de la   aplicación?

Si su respuesta es que puede comenzar a migrar, entonces modele su dominio real de la manera que lo desee. Persistir con repositorios y servicios normales. Diviértete diseñándolo de la manera que TÚ quieres que esté almacenado. Luego, use los servicios de las raíces agregadas para llegar a la capa anticorrupción y extraer las entidades, almacenarlas / actualizarlas localmente y traducirlas a las entidades de su dominio.

Si la respuesta es que el DB heredado permanecerá durante la vida del proyecto, entonces su tarea es mucho más fácil. Utilice los servicios de su dominio (por ejemplo, UserEmployeeService) para acceder a la UserFacade y EmployeeFacade anticorrupción (similar a un concepto de "Servicio Remoto").

Dentro de las fachadas, acceda a la base de datos heredada utilizando los adaptadores (por ejemplo, LegacyDbSqlDatabase) para obtener un usuario legacy sin procesar (). El siguiente paso sería usar un mapeador UserTranslator () y EmployeeTranslator () que convierta los datos de usuario heredados en la versión de su dominio real de la entidad User (), y los devuelva desde UserFacade a su UserEmployeeService, donde se combina con la entidad del empleado que vino del mismo lugar.

Whoa, eso fue mucho escribir ...

Con sus adaptadores y fachadas de su capa anticorrupción, puede hacer su Linq-to-Sql o lo que quiera hacer. No importa porque ha aislado por completo el sistema / base de datos heredado de su dominio agradable y puro: su dominio que tiene su propia versión de entidades de Usuario () y Empleado () y objetos de valor.

Answer 2

DDD y Linq To SQL no se combinan muy bien porque las clases generadas no tienen la intención de desviarse significativamente de la estructura de la tabla DB. Tendrá que asignar sus clases de una manera que haga que trabajar con Linq to SQL sea un dolor o simplemente vivir con un modelo de objeto no ideal.

Si realmente desea utilizar DDD y el patrón de repositorio, vaya a Entity Framework o incluso mejor NHibernate.