Il pattern del repository è procedurale, non OOP?

Question

Beh, ho letto un libro sul design basato sul dominio, è intitolato Patterns, Principles and Practices of Domain Driven Design (PPPDDD). Mi è piaciuto leggerlo finora e fornisce molte informazioni su DDD nel mondo .NET. Tuttavia, c'è una cosa che mi infastidisce molto. Nel capitolo 21 (modello Repository), l'autore ha effettuato queste due rivendicazioni:

rivendicazione 1:

Il repository non è un oggetto. È un limite procedurale e un contratto esplicito che richiede lo stesso sforzo quando si nominano metodi su di esso come fanno gli oggetti nel modello di dominio.

rivendicazione 2:

Il repository è il contratto tra il modello di dominio e di persistenza. Dovrebbe essere scritto solo in termini di dominio e senza un pensiero per il sottostante quadro di persistenza. Definire l'intento e renderlo esplicito; non trattare il contratto di repository come un codice orientato agli oggetti.

Quindi il modello di repository non è OOP, ma procedurale? Sei d'accordo con le affermazioni fatte dall'autore di questo libro? Perché l'esplicitazione dei metodi di repository, come findByUsername (string Username), rende il repository di natura procedurale?

Voglio scrivere codice OO, non codice procedurale. Se il repository è procedurale, uccide lo scopo di me usando questo modello. Spero davvero che cosa abbia detto l'autore non è vero, cosa ne pensi?

btw, ho fornito istantanee della sezione in cui l'autore del libro ha sostenuto repository è procedurale seguito, dare un'occhiata a loro se aiuta:

Answer 1

Il repository non è un oggetto. È un limite procedurale

Non sono affatto d'accordo. Un repository è una raccolta di cose.

Se GetAll() poi Add() qualcosa ad una Repo e poi GetAll() ancora una volta, non ci si aspetta di ottenere lo stesso risultato. La cosa si sta parlando è cambiato

=> Si ha uno stato interno, o almeno è così che sembra comportarsi al mondo esterno.

nasconde il suo stato interno, a.k.a. lo incapsula, poiché tutto ciò che è possibile accedere è l'interfaccia e non i dettagli di persistenza sottostanti.

È possibile passare i messaggi a un repository (chiamare i relativi metodi) e avere una "discussione" potenzialmente lunga con lo stesso repository.

Il modulo oggetto è perfettamente adatto per il tipo di lavoro svolto da un repository.

L'uso della parola procedurale nel libro è alquanto imbarazzante, fuorviante nel peggiore dei casi. Il fatto che abbia un contratto esplicito non ha nulla a che fare con uno stile procedurale di programmazione.

Answer 2

Penso che l'autore vuole sottolineare una certa punto, ma nel fare ciò crea confusione. Ad esempio

Il repository non è un oggetto.

Se non un oggetto, allora cosa? Il libro sembra essere nel contesto di .NET, quindi sicuramente l'autore non significa che dovremmo creare funzioni di repository statici. Sarebbe semplicemente ridicolo.

Posso assicurarti che un repository È un normale oggetto .NET.

Detto questo, non si "vede" gran parte della sua natura orientata agli oggetti quando lo si utilizza. Un repository è un oggetto simile a un servizio che appare "piatto", cioè non espone una struttura di oggetti navigabile, solo metodi.Questo è affermato dall'autore nella frase

non trattare il contratto repository come oggetto codice orientato

Un'altra affermazione,

Definire intento e renderlo esplicito

è spesso ignorato nella mia esperienza. Spesso vengono create implementazioni di repository generiche in grado di gestire tutti i tipi di oggetti di dominio. Anche se all'inizio potrebbe sembrare una buona idea, non è nello spirito del DDD. È necessario creare repository con metodi di ricerca esplicita che siano supportati da nel contesto del proprio dominio.

Quindi con questo fuori strada, penso che la tua paura del codice procedurale sia probabilmente ingiustificata. C# è un linguaggio a paradigma misto, e la programmazione nel piccolo è spesso procedurale, programmazione imperativa. Con le nuove funzionalità linguistiche è diventato sempre più semplice affrontare gli stessi problemi con la programmazione funzionale (di cui sono anche un grande fan), ad es. con LINQ, ma questo non rende cattivi gli stili procedurali. E la programmazione nel grande avviene ancora in un modo orientato agli oggetti.