Mejores prácticas de la capa de datos

Question

Estoy en medio de una "discusión" con un colega sobre la mejor manera de implementar la capa de datos en una nueva aplicación.

Un punto de vista es que la capa de datos debe tener en cuenta objetos comerciales (nuestras propias clases que representan una entidad), y poder trabajar con ese objeto de forma nativa.

El punto de vista opuesto es que la capa de datos debe ser agnóstico a objetos, y puramente manejar tipos de datos simples (cadenas, Bools, fechas, etc.)

puedo ver que ambos enfoques pueden ser válidas, pero mi propio punto de vista es que prefiero el primero. De esta forma, si el medio de almacenamiento de datos cambia, la capa empresarial no debe (necesariamente) cambiar para adaptarse a la nueva capa de datos. Por lo tanto, sería una cosa trivial cambiar de un almacén de datos SQL a un almacén de sistema de archivos xml serializado.

El punto de vista de mi colega es que la capa de datos no debería tener que conocer las definiciones de los objetos, y que, siempre que los datos se pasen de forma adecuada, es suficiente.

Ahora, sé que esta es una de esas preguntas que tiene el potencial de comenzar una guerra religiosa, pero agradecería cualquier comentario de la comunidad sobre cómo abordas esas cosas.

TIA

Answer 1

Realmente depende de su visión del mundo - Yo solía estar en el campo desacoplado. El DAL solo estaba allí para suministrar datos al BAL: fin de la historia.

Con tecnologías emergentes como Linq a SQL y Entity Framework volviéndose un poco más populares, entonces la línea entre DAL y BAL se ha difuminado un poco. En L2S, especialmente su DAL está bastante acoplado a los objetos Business ya que el modelo de objetos tiene una asignación de 1-1 a su campo de base de datos.

Como en el desarrollo de software, no hay una respuesta correcta o incorrecta. Debe comprender sus requisitos y requisitos futuros y trabajar desde allí. No usaría más un Ferrari en el rally Dakhar como lo haría con un Range Rover en un día de pista.

Answer 2

Un excelente libro que tengo, que cubre este tema, es Data Access Patterns, por Clifton Nock. Tiene muchas buenas explicaciones y buenas ideas sobre cómo desacoplar la capa de negocio de la capa de persistencia. Realmente deberías intentarlo. Es uno de mis libros favoritos.

Answer 3

Un truco que he encontrado útil es que mi capa de datos sea "independiente de la colección". Es decir, cada vez que deseo devolver una lista de objetos de mi capa de datos, hago que la persona que llama pase en la lista. Así que en lugar de esto:

public IList<Foo> GetFoosById(int id) { ... } 

hago esto:

public void GetFoosById(IList<Foo> foos, int id) { ... } 

Esto me permite pasar de una lista a secas si eso es todo lo que necesito, o una aplicación más inteligente de IList <T> (como ObservableCollection <T>) si planeo vincularlo desde la IU. Esta técnica también me permite devolver cosas del método como un ValidationResult que contiene un mensaje de error, si se produjo.

Esto todavía significa que mi capa de datos conoce mis definiciones de objeto, pero me da un grado adicional de flexibilidad.

Answer 4

Compruebe Linq a SQL, si estuviera creando una nueva aplicación en este momento, consideraría confiar en una capa de datos totalmente basada en Linq.

Aparte de eso, creo que es una buena práctica desacoplar datos y lógica tanto como sea posible, pero eso no siempre es práctico. Una separación pura entre la lógica y el acceso a los datos hace que las uniones y optimizaciones sean difíciles, que es lo que hace que Linq sea tan poderoso.

Answer 5

Puede tener ambos. Permita que la capa de datos no conozca sus objetos de negocio y sea capaz de trabajar con más de un tipo de fuentes de datos. Si proporciona una interfaz común (o una clase abstracta) para interactuar con datos, puede tener diferentes implementaciones para cada tipo de fuente de datos. El patrón de fábrica va bien aquí.

Answer 6

Jeffrey Palermo escribió una buena publicación sobre esto. Lo llamó Onion Architecture.

Answer 7

En aplicaciones en las que utilizamos NHibernate, la respuesta se convierte en "en algún punto intermedio", mientras que las definiciones de mapeo XML (especifican qué tabla pertenece a qué objeto y qué columnas pertenecen a qué campo, etc.) están claramente el nivel de objeto de negocio.

Se pasan a un administrador de sesión de datos genérico que no tiene conocimiento de ninguno de los objetos comerciales; el único requisito es que los objetos comerciales que se le pasen para CRUD deben tener un archivo de mapeo.

Answer 8

Publicación anterior pero buscando información similar Me encontré con this que lo explica muy bien.