Repositorios múltiples o únicos con LINQ

Question

He estado leyendo el Capítulo 11 (Patrones de diseño comprobables) en el libro Professional ASP.NET MVC 1.0. En los ejemplos de este capítulo, el acceso a los datos se divide en varios repositorios: IOrderRepository, IProductRepository, etc. Todo eso tiene sentido: un único repositorio para una sola clase de datos.

Sin embargo, esto se rompe un poco para mí cuando se consideran los enlaces entre las tablas: una Orden contiene una cantidad de Productos. Cuando la clase de orden es creada por LINQ-to-SQL, la clase de orden tendrá una colección de productos que enumera todos los productos relacionados con esa orden. Entonces, al usar esta colección, pasamos por alto el ProductsRepository.

Por lo tanto, cuando se burla, no solo voy a tener que burlarme del OrderRepository y del ProductRepository, también voy a tener que rellenar la colección Products en los objetos Order devueltos. Lo que significa que el OrderRepository burlado tiene que saber sobre el ProductSerpository burlado, etc.

Parece una pérdida ignorar estas colecciones que LINQ tan amablemente creó para mí, así que mi pregunta es, en este caso, ¿no tendría más sentido un solo repositorio?

Answer 1

Otros factores a considerar incluyen la probable vida útil del producto y la probabilidad de tener que cambiar de LINQ-to-SQL a algún otro asignador de O/R en cualquier punto en el tiempo de vida. Cuanto más pequeño sea el proyecto, menos crítico es el producto, menos tendrá que preocuparse por abstraer minutas al enésimo grado.

Answer 2

La descripción del problema es un ejemplo de libro de texto típico cuando demasiado blabla sobre 'esto es bueno, eso es malo' se convierte en la razón por la cual un desarrollador crea el software tal como se creó en vez de mirar el problema y crear software para arreglar ese problema

Caso en cuestión: la descripción de su problema no es su problema para resolver: tiene una aplicación para crear para su cliente, ese es el problema que debe resolver. Si su elección de herramientas le dificulta la vida, eche a un lado y use lo que funciona: si la burla no funciona, ¿para qué molestarse? Oh, ¿porque alguien dijo que tu software apestará si no te burlas? ¿Por qué?

Has recogido algunas cosas de DDD aquí y allá, pero te has perdido algunas partes importantes: El producto es una raíz agregada. Esto significa que debe obtener productos de su propio repositorio. Sí, eso mitiga la función de navegación en el modelo, pero eso es DDD para usted, SI crea los repositorios estrictamente como dicta la segunda parte del libro de Evans. Pero ... ¿deberías?

Si no puede responder por qué el Producto tiene su propio repositorio, pero puede navegar hasta los productos desde Orden, no debe crear repositorios para raíces agregadas. ¿POR QUÉ es ese depósito allí? Si está allí, ¿no debería ser el ÚNICO punto en el que se pueden obtener productos? (¡así que tampoco a través de la carga floja!).

De hecho, esto creará muchos sobrecargas y códigos que probablemente no necesitará (así que irónicamente, YAGNI en pleno efecto).

Ok, suficiente despotricando. DDD se trata de pensando. Entonces, el dominio debe conducir el diseño, y al practicar eso, obtendrás un modelo de dominio que representa la realidad. Eso no quiere decir que debas implementar una gran cantidad de código solo porque leas en algún lugar que deberías. En cambio, si ha reconocido los elementos del dominio, las raíces agregadas, etc., debe colocar el comportamiento para estos tipos en algún lugar, p. dentro de las clases de dominio. Puede colocar la lógica de búsqueda en clases separadas, como la lógica de búsqueda orientada a órdenes en un repositorio de órdenes, pero no será un repositorio en sentido estricto (por ejemplo, no tiene su propia memoria caché local, etc.). Eso no es tan malo, se trata de lo que debe crear para su cliente.

Entonces, primero: pensar, segundo: pensar, y tercero: pensar ... otra vez. Lo que parece lógico para ti Haga una lista de pros/contras de las opciones que tiene y elija la que le parezca más adecuada. Documenta esa elección y por qué elegiste esa y no las alternativas.Esto les da más valor a los mantenedores que a cualquier otra fuente: documentas las alternativas y por qué no las elegiste, investigas qué funcionará para ti y eliges una.

Ingeniería de software no es difícil, pero es que hoy en día parece la manera con que se haga primero y pensar después, sin una motivación adecuada qué uno podría hacerlo de esa manera y no a la inversa.

Buena suerte :)