Un repositorio por mesa o uno por sección funcional?

Question

Estoy usando ASP.NET MVC 2 y C# con Entity Framework 4.0 para codificar contra una base de datos SQL Server normalizada. Una parte de la estructura de mi base de datos contiene una tabla de entradas con claves externas relacionadas con tablas secundarias que contienen controladores, automóviles, motores, chasis, etc.

Estoy siguiendo el tutorial Nerd Dinner que configura un repositorio para cenas que es justo suficiente. ¿Hago uno para los conductores, uno para los motores, uno para los automóviles, etc. o hago uno grande para las entradas?

¿Cuál es la mejor práctica para este tipo de trabajo? Todavía soy nuevo en este método de codificación.

Answer 1

Supongo que realmente no hay una sola "mejor práctica" para esto, depende de su estilo de codificación y los requisitos para su aplicación. Definitivamente puede crear un repositorio para cada tipo de entidad en su sistema, eso funcionará perfectamente.

En su caso aquí, probablemente al menos consideraría tener un repositorio para los conductores, y posiblemente un segundo para los automóviles, motores, chasis (ya que están en la misma área de experiencia, están interconectados, "pertenecer" juntos).

Pero, por supuesto, si ese repositorio único para automóviles, motor y chasis se hincha demasiado, podría considerar dividirlo en tres repositorios separados.

Intentaré encontrar un equilibrio entre la cantidad de repositorios (intente agrupar lo que lógicamente pertenece) y la cantidad de métodos en esos repositorios. Cinco, diez métodos están bien; si estás hablando de 20, 30 o 50 métodos, tu repositorio podría ser demasiado grande e inmanejable.

Definitivamente es una decisión arquitectónica, y como tal, en realidad no son muchos hechos concretos que lo guíen: es más un "presentimiento" y un tipo de experiencia. Si aún no tiene esa experiencia necesaria, siga un enfoque, utilícelo y, cuando termine, mírelo nuevamente con ojo crítico y vea: ¿qué funcionó? ¿Qué pasa con eso no funcionó? y luego en su próximo proyecto, pruebe otro enfoque y cuestione su validez, también, al final del proyecto. ¡Vive y aprende!

Answer 2

Estoy usando un repositorio genérico (parametrizado) para cada entidad. Este repositorio contiene la función CRUD básica. Por encima de eso tengo servicio para cada funcionalidad. Cada servicio instancia los repositorios necesarios. ObjectContext es común para todos ellos y hay uno para cada solicitud. Esta es mi interfaz de repositorio:

public interface IRepository<T> 
{ 
    //Retrieves list of items in table 
    IQueryable<T> List(); 
    IQueryable<T> List(params string[] includes); 

    //Creates from detached item 
    void Create(T item); 
    void Delete(int id); 
    T Get(int id); 
    T Get(int id, params string[] includes); 
    void SaveChanges(); 
} 

También tengo una implementación genérica, que es larga, pero fácil de implementar. No tendrá que crear una clase de repositorio para cada tipo, simplemente instale Repository<Type>.

Answer 3

Personalmente hablando, me parece mejor crear un repositorio separado para cada tabla.

Luego creo un services layer donde en una clase ejecutaba todos los comandos para una acción específica (por ejemplo, cambiar el coche de un conductor existente por uno nuevo). La capa de servicios es donde llamaré al repositorio múltiple si una acción que necesito hacer contiene múltiples objetos que están interrelacionados.

Intento mi mejor esfuerzo para mantener mis repositorios lo más "tontos posible" y poner todas las cosas "inteligentes" en la capa de servicios. La capa adicional services también me ayuda a evitar la hinchazón de mis controladores.

Answer 4

Normalmente tomo el diagrama de la base de datos y dibujo círculos alrededor de lo que consisto en una unidad o sistema más grande.

Eso me da algo así como "Sistema de producto", "Sistema de pedido", "Sistema de usuario", "Sistema de pago" en una tienda.

Si los sistemas se vuelven demasiado grandes, los dejo.

Si los sistemas son demasiado pequeños, no me importa: todo crecerá de todos modos.

Si algo pertenece de alguna manera a 2 sistemas, elijo 1 y no lo cambio más, incluso si al día siguiente las decisiones fallan: sé que llegará el día en que quiero volver a cambiarlo.