Repository efficace in C # - Dove mettere i metodi?

0

Sto provando a creare una nuova applicazione utilizzando il modello di repository per la prima volta e sono un po 'confuso sull'utilizzo di un repository. Supponiamo che abbia le seguenti classi:

public class Ticket
{

}
public class User
{
   public List<Ticket>AssignedTickets { get; set; }
}
public class Group
{
   public List<User> GroupMembers { get;set; }
   public List<Ticket> GroupAssignedTickets { get;set; }
}

Ho bisogno di metodi che possano popolare queste raccolte recuperando i dati dal database.

Sono confuso su quale classe di repository associata dovrei inserire quei metodi. Devo progettare i miei repository in modo che tutto il ritorno di tipo T vada nel repository per il tipo T in quanto tale?

public class TicketRepository
{
   public List<Ticket> GetTicketsForGroup(Group g) { }
   public List<Ticket> GetTicketsForUser(User u) { }
}
public class UserRepository
{
  public List<User> GetMembersForGroup(Group g) { }
}

L'ovvio inconveniente che vedo qui è che ho bisogno di avviare l'istanziazione di molti repository. Cosa succede se il mio utente ha assegnato anche widget, Fidgets e Lidgets? Quando popolino un utente, ho bisogno di creare un'istanza di un WidgetRepository, un FidgetRepository e un LidgetRepository per popolare un singolo utente.

In alternativa, costruisco il mio repository in modo che tutto requesting basato sul tipo T sia raggruppato nel repository per il tipo T come elencato di seguito?

public class GroupRepository
{
    public List<Ticket> GetTickets(Group g) { }
    public List<User> GetMembers(Group g) { }
}
public class UserRepository
{
   public List<Ticket> GetTickets(User u) { }
}

Il vantaggio che vedo qui è che se ora ho bisogno che il mio utente abbia una raccolta di Widget, Fidgets e Lidgets, aggiungo semplicemente i metodi necessari al pattern UserRepository e non ho bisogno di creare un'istanza di un WidgetRepository, FidgetRepository, e LigetRepository class ogni volta che voglio creare un utente, ma ora ho sparpagliato le preoccupazioni per un utente attraverso diversi repository.

Non sono davvero sicuro di quale sia la strada giusta, se esiste. Qualche suggerimento?

    
posta ravibhagw 31.07.2014 - 15:16
fonte

2 risposte

0

Come risulta, la prima opzione era l'opzione più pratica in questo caso. C'erano alcuni motivi per questo:

1) Quando si apportano modifiche a un tipo e al relativo repository associato (si presume Ticket), è stato molto più semplice modificare Ticket e TicketRepository in un'unica posizione piuttosto che inseguire ogni metodo in ogni repository che utilizzava un Ticket.

2) Quando ho tentato di utilizzare le interfacce per dettare il tipo di code che ogni repository poteva estrarre, ho riscontrato problemi in cui un singolo repository non poteva implementare un'interfaccia generica utilizzando il tipo T più volte con l'unica differenziazione nell'implementazione del metodo di interfaccia essendo il tipo di parametro.

3) Accedo ai dati da SharePoint e un database nella mia implementazione e ho creato due classi astratte per fornire strumenti di dati ai repository concreti per Sharepoint o SQL Server. Supponiamo che nell'esempio sopra gli utenti provengano da Sharepoint mentre i biglietti provengono da un database. Usando il mio modello non sarei in grado di utilizzare queste classi astratte, poiché il gruppo dovrebbe ereditare sia dalla mia classe astratta di Sharepoint sia dalla mia classe astratta SQL. C # non supporta l'ereditarietà multipla di classi astratte. Tuttavia, se sto raggruppando tutti i comportamenti relativi ai ticket in un TicketRepository e tutti i comportamenti relativi all'utente in un UserRepository, ciascun repository deve solo accedere a un tipo di origine dati sottostante (SQL o Sharepoint, rispettivamente).

    
risposta data 06.08.2014 - 16:15
fonte
0

La seconda opzione sembra che tu stia definendo il tuo repository in base ai tuoi requisiti per questa determinata applicazione rispetto a 1 repository per "tabella" che potrebbe essere più flessibile per altre aree della tua app che potrebbero emergere o altre applicazioni che potrebbero non raggrupparsi cose come fa la tua app attuale. Sì, significa che avrai una buona quantità di repository, ma poi sono riutilizzabili all'interno di qualsiasi progetto che ha bisogno di accedere a tale repository.

Generalmente creo repository per "table" (lavoro principalmente in DB) e poi creo classi di "servizio" (alcuni dicono che pensi di UnitofWork) quei repository di gruppo e ha un'interfaccia per dare funzionalità a quel servizio.

    
risposta data 31.07.2014 - 15:42
fonte

Leggi altre domande sui tag