MVC: repositorios y servicios

Question

Estoy confundido en cuanto a las limitaciones de lo que se define en los Repositorios y qué dejar a los Servicios. ¿Debería el repositorio solo crear entidades simples que coincidan con tablas de la base de datos o puede crear objetos complejos personalizados con combinaciones de esas entidades?

en otras palabras: ¿Deberían los Servicios realizar varias consultas de Linq a SQL en el Repositorio? ¿O todas las consultas deben estar predefinidas en el Repositorio y la lógica de negocios simplemente decide a qué método llamar?

Answer 1

Realmente ha planteado una pregunta aquí que actualmente está generando mucha discusión en la comunidad de desarrolladores; consulte los comentarios de seguimiento a ¿Debería mi repositorio exponer IQueryable?

El repositorio puede, y debe, crear objetos combinados complejos que contengan múltiples entidades asociadas. En el diseño controlado por dominio, estos se denominan agregados , colecciones de objetos asociados organizados en una estructura cohesiva. Su código no tiene que llamar a GetCustomer () , GetOrdersForCustomer () , GetInvoicesForCustomer () por separado; simplemente llame a myCustomerRepository. Carga (customerId) , y obtienes un objeto de cliente profundo con esas propiedades ya instanciadas. También debería agregar que si está devolviendo objetos individuales basados ??en tablas de bases de datos específicas, entonces ese es un enfoque perfectamente válido, pero en realidad no es un repositorio per s & # 233; , es solo un acceso a datos capa.

Por un lado, hay un argumento convincente de que los objetos Linq-to-SQL, con sus propiedades 'inteligentes' y su ejecución diferida (es decir, no cargar Customer.Orders hasta que realmente lo use) son una implementación completamente válida de patrón de repositorio, porque en realidad no está ejecutando código de base de datos, está ejecutando instrucciones LINQ (que luego se traducen en código DB por el proveedor LINQ subyacente)

Por otro lado, como señala la publicación de Matt Briggs, L2S está bastante estrechamente acoplado a la estructura de su base de datos (una clase por tabla) y tiene limitaciones (no hay muchas, muchas asignaciones, por ejemplo), y puede ser mejor use L2S para acceder a los datos dentro de su repositorio, pero luego asigne los objetos L2S a sus propios objetos de modelo de dominio y devuélvalos.

Answer 2

Un repositorio debe ser la única pieza de su aplicación que sepa algo sobre su tecnología de acceso a datos. Por lo tanto, no debería devolver objetos generados por L2S, sino asignar esas propiedades para modelar objetos propios.

Si está utilizando este tipo de patrón, es posible que desee volver a pensar en L2S. Genera una capa de acceso a datos para usted, pero en realidad no maneja la falta de coincidencia de impedancia, debe hacerlo manualmente. Si observa algo como NHibernate, ese mapeo se realiza de una manera más robusta. L2S es más para una aplicación de 2 niveles, donde desea un DAL rápido y sucio que pueda ampliar fácilmente.

Answer 3

Si está utilizando LINQ, creo que el repositorio debería ser un contenedor para su sintaxis LINQ. Esto le brinda un nivel de abstracción de las rutinas de acceso a la base de datos desde la interfaz de su objeto modelo. Como Dylan menciona anteriormente, hay otras opiniones sobre el asunto, a algunas personas les gusta devolver el IQueryable para que puedan continuar consultando la base de datos en un punto posterior después del repositorio. No hay nada de malo en ninguno de estos enfoques, siempre y cuando tenga claros sus estándares para su aplicación. Hay más información sobre las mejores prácticas que uso para los repositorios de LINQ aquí.