¿Clases de depósito individuales o múltiples?

Question

Mi base de datos es relativamente pequeña, 8 tablas, cada una con menos de 5 columnas. Yo uso EF. Creé una sola clase de repositorio, pero ahora creo que podría no ser la forma correcta de usarlo. ¿Debería tener una clase de repositorio separada para cada uno de mis controladores? Digamos que tengo Productos, Usuarios, Unicornios ¿estaría bien tener una sola clase de repositorio para operar con todos esos e instanciar en cada uno de esos controladores, o debería crear una clase de repositorio separada para cada uno de ellos?

Answer 1

Uno de los conceptos fundamentales de DDD es la raíz agregada: esta es la entidad de "nivel superior" a través de la cual se administran conjuntos completos de entidades relacionadas. Por ejemplo, en un escenario minorista, la 'Orden' sería una raíz agregada a través de la cual podría acceder al Pedido en sí, una lista de Artículos de pedido (es decir, Producto + Importe + modificadores como descuentos), BillingAddress, ShippingAddress y PaymentMethod. . Cada uno de ellos está estrechamente relacionado con el orden en sí, hasta el punto en que no tienen ningún motivo para existir fuera del alcance del pedido.

Cada raíz de agregado debe tener un repositorio que sea el propietario de la persistencia de todo el subgráfico de objetos debajo de la raíz. Por lo tanto, en el ejemplo anterior, NO querrá ni necesitará un repositorio para artículos de pedido que permita el acceso para pedir artículos de manera independiente; en su lugar, debe implementar un solo OrdersRepository que trate los pedidos y todos sus subcomponentes como una sola unidad.

Dependiendo de su modelo de dominio específico puede necesitar uno o más repositorios, pero ciertamente no uno por tipo de entidad. La pregunta clave que debe hacerse cuando se buscan raíces agregadas es "¿esta entidad tiene su propia identidad y ciclo de vida?" Las órdenes lo hacen, OrderItems no.

Answer 2

No creo que un repoistory por entidad sea una buena idea, más bien un repositorio por servicio si eso tiene algún sentido.

por ejemplo, yo no iría y haría un CategoriesRepository o CarsRepository si el enfoque principal de mi aplicación está en Users.

Answer 3

Think Domain-Driven Design, y con eso en mente, divide la estructura lógica de su proyecto no solo como clases, sino también como dominios, lo que significa que todas las operaciones tienen que ver con Product se encuentran dentro del ProductsController y consecuentemente dentro del ProductsRepository, así que prefiero muchos repositorios, cada uno equipado con operaciones para tratar con algún aspecto de su proyecto.

No todos los aspectos pueden necesitar un repositorio, pero eso es lo que usted decide.