Pattern di repository senza framework di entità?

3

È possibile implementare il modello di repository senza utilizzare il framework di entità?

Sto lavorando su un piccolo team di sviluppo di 3 su una soluzione ASP.NET MVC su piccola scala (per ora). Ho detto al mio manager che penso che abbiamo bisogno di un livello di astrazione tra la nostra logica aziendale e i nostri controllori. In questo momento i nostri controller contengono molte delle logiche di business che si verificano e altre funzionalità, che so essere una cattiva pratica.

Ho usato il pattern del repository in passato nella mia ultima posizione, ma non l'ho implementato lì. E non posso dire di avere il 100% di "pensare" al modello e sapere come implementarlo da solo. Ci sono così tanti tutorial là fuori per questo modello e sembrano tutti differire di solito, anche se è una leggera differenza.

Un'altra mia preoccupazione è che l'altro programmatore del mio team (senior dev) ha affermato che non è necessario passare a EF in questo momento. Penso che il nostro progetto sia ancora piccolo e non abbiamo il tempo di fare il passaggio. Rispetto e capisco questo, quindi mi chiedo se sia possibile utilizzare questo modello anche senza EF.

Se sì, qualcuno ha tutorial, esempi o riferimenti utili?

Se no, cosa dovrei cercare di fare dopo? Non voglio presentarmi a mani vuote. Potrei semplicemente rappresentare i nostri oggetti (reali) come classi che memorizzano e forniscono funzionalità. In questo modo ci si spera che ci sia meno logica e funzionalità da eseguire nei controller.

Grazie per la lettura.

    
posta user1977591 08.01.2015 - 15:31
fonte

1 risposta

4

I modelli di progettazione come il pattern di repository non dipendono da una particolare tecnologia, quindi la risposta ovvia alla tua domanda è "sì, certo che puoi". È possibile scrivere repository che in ultima analisi sono supportati da qualsiasi tecnologia di storage: il punto è che il pattern Repository è un modo per strutturare il codice di accesso ai dati e separarlo dall'altro codice. È descritto in modo tale da essere indipendente dal linguaggio di programmazione, a condizione che la lingua in questione abbia oggetti e l'ereditarietà dell'interfaccia che puoi far funzionare.

Ciò che non è è un modo di strutturare la tua logica aziendale e separarla dai tuoi controller di visualizzazione, che è ciò che la tua spiegazione dice effettivamente di cui hai bisogno. Per questo hai una serie di altre opzioni disponibili. Dove lavoro scriviamo una serie di oggetti Servizio che forniscono la logica aziendale, e i controllori li chiamano (a loro volta hanno oggetti del repository iniettati dal framework DI per consentire loro di accedere all'archiviazione dei dati senza dover conoscere tutti i dettagli). I controllori contengono quindi solo il codice che si occupa dell'elaborazione dei dati in arrivo dall'interfaccia utente in un modulo che i servizi possono gestire e che trasforma le risposte del servizio in qualcosa di adatto per la visualizzazione all'utente.

    
risposta data 08.01.2015 - 16:49
fonte

Leggi altre domande sui tag