Mejores prácticas de 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 conocer los 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 independiente de los objetos y manejar exclusivamente tipos de datos simples (cadenas, bools, fechas, etc.)

Puedo ver que ambos enfoques pueden ser válidos, pero mi punto de vista es que prefiero el primero.De esa manera, si el medio de almacenamiento de datos cambia, la capa empresarial no tiene (necesariamente) que cambiar para adaptarse a la nueva capa de datos.Por lo tanto, sería 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 objetos, y que siempre que los datos se transmitan de manera adecuada, eso es suficiente.

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

tia

Answer 1

Realmente depende de tu visión del mundo: yo solía estar en el campo de los desconectados.El DAL sólo estaba allí para suministrar datos al BAL - fin de la historia.

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

Como todo en el desarrollo de software, no existe una respuesta correcta o incorrecta.Debe comprender sus requisitos y los requisitos futuros y trabajar desde allí.Ya no utilizaría un Ferrari en el rally Dakhar como lo haría con un Range Rover en un día de pista.

Answer 2

Puedes tener ambos.Deje que la capa de datos no conozca los objetos de su negocio y hágala 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 3

Un excelente libro que tengo, que cubre este tema, es Patrones de acceso a datos, de Clifton Nock.Tiene muchas buenas explicaciones y buenas ideas sobre cómo desacoplar la capa empresarial de la capa de persistencia.Realmente deberías intentarlo.Es uno de mis libros favoritos.

Answer 4

Jeffrey Palermo escribió una buena publicación sobre esto.el lo llamo Arquitectura de cebolla.

Answer 5

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

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

Hago esto:

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

Esto me permite pasar una Lista antigua y simple si eso es todo lo que necesito, o una implementación más inteligente de IList<T> (como ObservableCollection<T>) si planeo vincularme a ella desde la interfaz de usuario.Esta técnica también me permite devolver cosas del método como ValidationResult que contiene un mensaje de error si se produjo alguno.

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

Answer 6

Consulte Linq to SQL. Si estuviera creando una nueva aplicación ahora mismo, consideraría confiar en una capa de datos completamente basada en Linq.

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

Answer 7

En las aplicaciones en las que usamos NHibernate, la respuesta se convierte en "en algún punto intermedio", en el sentido de que, 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 en el nivel de objeto de negocio. .

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

Answer 8

Publicación antigua pero encontré información similar este lo cual lo explica muy bien.