Posso racchiudere una collezione con una classe statica e chiamarla ancora pattern di repository?

Question

Posso racchiudere una collezione con una classe statica e chiamarla ancora pattern di repository?

#1 da (3 voti)
#2 da (1 voti)

3

Non sono riuscito a trovare un singolo esempio sul modello di repository usando qualcos'altro di un database.

Il mio obiettivo è avere un repository globale statico che memorizza alcuni oggetti in memoria. Non voglio che sia un singleton con la proprietà Instance perché non ha alcuna funzione speciale ma Aggiungi / Removoe ... proprio come un repository.

Quindi supponiamo di voler mantenere una collezione di convertitori di oggetti da qualche parte nella memoria. Sto abusando del modello di repository per questo (perché sembra essere la soluzione più adatta qui)? O lo chiami qualcos'altro e il deposito è riservato solo a database o altri tipi di archiviazione?

public static ConvertersRepository : IConvertersRepository
{
    // this is the actual collection
    private static IList<IObjectConvereter> _converters = new List<IObjectConvereter>;
    public static void AddObjectConverter(IObjectConvereter...) {}
    public static IObjectConvereter GetObjectConverter(...) {}
}

c# refactoring design-patterns

posta t3chb0t 09.11.2015 - 20:40

fonte

2 risposte

1

L'origine dati non significa database. Potresti avere perfettamente un repository che parla con un servizio remoto invece che con un DB. La cosa importante è che dal punto di vista del codice client, il repository ha l'aspetto di una raccolta che puoi esaminare, aggiungere o rimuovere da. È un'astrazione utile.

Da PoEAA di Martin Fowler:

A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection

Probabilmente c'è molto da dire sulla natura statica del tuo repository, in particolare perché un metodo statico non può implementare un'interfaccia , ma nello spirito penso che soddisfi il contratto.

risposta data 10.11.2015 - 10:52

fonte

Leggi altre domande sui tag c# refactoring design-patterns

Vantaggi dell'estensione della classe Exception predefinita Vantaggi dello stile imperativo rispetto allo stile funzionale [duplicato]

score 3 · Accepted Answer

Dichiarazione di non responsabilità: ho cercato lo schema del repository perché non ne avevo mai sentito parlare prima con questo nome. Per me sembra proprio un wrapper standard attorno al livello di persistenza / database.

È normale usare wrapper attorno all'accesso ai dati e modificare l'implementazione dietro il wrapper mentre il progetto avanza, e alcune delle prime implementazioni spesso non persistono nemmeno i dati sul disco. Quindi, per il modello che conosco, che penso sia il modello di repository di cui parli, non importa se i dati sono memorizzati in un database. Tutto ciò che conta è che possa essere memorizzato in un database, ma questa è l'implementazione. Tuttavia, il modello implica strongmente persistenza, quindi non direi che stai davvero utilizzando il modello di repository qui.

La tua domanda ha due parti. Una parte è la domanda se quello che stai facendo è il pattern di Repository, l'altro è se va bene chiamare qualcosa XyzRepository se non implementa il pattern di Repository.

Questa seconda domanda dipende dalla totalità della base di codici tua o della tua azienda. Ho visto molte codebase con molte classi chiamate ...Repository che non avevano nulla a che fare con la persistenza di qualcosa sul disco. In un caso generale, è perfettamente normale chiamare una classe che è un repository di xyz XyzRepository . E ciò che la tua domanda descrive sicuramente è un deposito di convertitori. Tuttavia (!), se in un caso specifico si ha una base di codice in cui tutte le altre classi che sono nominate ... Il repository include una memoria permanente, quindi usando il nome per qualcosa che non offre la persistenza può essere confuso o fuorviante, e quindi dovrebbe essere evitato.

Un elenco di nomi alternativi ma non necessariamente migliori: %codice% %codice% %codice% %codice% %codice% Converters