Patrón de asignador de datos

Question

Hasta ahora he estado usando registros activos en todas mis aplicaciones basadas en bases de datos C#. Pero ahora mi aplicación requiere que mi código de persistencia se divida desde mis objetos comerciales. He leído muchas publicaciones sobre el patrón de mapeo de datos de Martin Fowler, pero mi conocimiento de este patrón sigue siendo muy limitado.

Vamos a utilizar el siguiente ejemplo:

Si tengo 2 mesas - Cliente y CustomerParameters. La tabla CustomerParameters contiene los valores predeterminados del Cliente para crear un nuevo Cliente.

Tendré que crear una clase CustomersMapper para manejar toda la persistencia del cliente. Mi clase Cliente y Lista de clientes colaborará con esta clase de asignador para conservar los datos del cliente.

tengo las siguientes preguntas:

1. ¿Cómo iba a transferir datos sin formato a & de mi clase de cliente al asignador sin romper ciertas reglas de negocio? ¿DTO?

2. ¿Es aceptable tener un método SaveAll y LoadAll en mi clase Mapper para actualizar y cargar datos de múltiples clientes? Si es así, en el caso de SaveAll, ¿cómo sabrá el mapeador cuándo actualizar o insertar datos?

3. ¿La clase de correlacionador de clientes será responsable de recuperar los valores predeterminados de la tabla CustomerParameters, o será mejor crear un asignador CustomerParameters?

Una herramienta O/R mapper no está realmente aquí. La base de datos que estoy usando es Transaccional y requiere que escriba mi propio Patrón de Mapper.

Todas las ideas y comentarios serán muy apreciados.

Answer 1

Sugiero que eche un vistazo a una herramienta de correlación de O/R antes de intentar implementar el patrón de Data Mapper usted mismo. Esto le ahorrará mucho tiempo. Una opción popular de O/R-mapper es NHibernate.

Answer 2

Shaun me gustaría responder a sus preguntas de esta manera:

ad 1) Mapper es responsable de la creación de objetos de cliente. Su objeto Mapper tendrá algo así como el método RetrieveById (por ejemplo). Aceptará una identificación y de alguna manera (que es responsabilidad del objeto Mapper) construirá el objeto Customer válido. Lo mismo es cierto a la inversa. Cuando llama al método Mapper.Update con un objeto Cliente válido, el objeto Mapper es responsable de asegurarse de que todos los datos relevantes se mantienen (cuando corresponda: db, memoria, archivo, etc.)

public 2) Como yo notado anteriormente recuperar/persistir son métodos en el objeto Mapper. Es su responsabilidad proporcionar tal funcionalidad. Por lo tanto, LoadAll, SaveAll (probablemente pasando una matriz de objetos de valor) son métodos válidos de Mapper.

anuncio 3) Yo diría que sí. Pero puede separar varios aspectos de los objetos de Mapper en clases separadas (si lo desea/necesita): valores predeterminados, validación de reglas, etc.

Espero que ayude. Realmente te sugiero/recomiendo leer el libro de Martin Fowler Patterns of Enterprise Application Architecture.

Answer 3

Puedes echar un vistazo a iBATIS.NET como una alternativa a NHibernate. También es una herramienta de O/R, pero he descubierto que es un poco más fácil de usar que NHibernate.

http://ibatis.apache.org/