Repository Pattern στο .NET: Είναι πραγματικά ξεπερασμένο επειδή το Entity Framework Core το υλοποιεί ήδη;

[kasenur]

Υπότιτλος: Clean Architecture, Dependency Inversion, αρχιτεκτονικά όρια και οι πραγματικοί συμβιβασμοί πίσω από τα custom repositories.

Κάθε τόσο επανέρχεται στις κοινότητες των .NET developers η ίδια συζήτηση:

«Γιατί χρησιμοποιείς Repository Pattern; Το Entity Framework Core υλοποιεί ήδη Repository και Unit of Work. Η επιπλέον αφαίρεση είναι περιττή και ξεπερασμένη».

Με την πρώτη ματιά, το επιχείρημα ακούγεται λογικό. Το Entity Framework Core παρέχει το DbSet<T> για την εργασία με οντότητες και το DbContext για την παρακολούθηση αλλαγών και την αποθήκευσή τους. Γιατί, λοιπόν, να προσθέσουμε επιπλέον interfaces και κλάσεις που φαίνεται να κάνουν ακριβώς το ίδιο πράγμα;

Ωστόσο, αυτή η συζήτηση συχνά συγχέει δύο διαφορετικά ερωτήματα:

Παρέχει το Entity Framework Core λειτουργίες αντίστοιχες με Repository και Unit of Work;
Σημαίνει αυτό ότι ένα custom Repository δεν έχει αρχιτεκτονική αξία;

Στο πρώτο ερώτημα η απάντηση είναι ναι. Στο δεύτερο, όχι.

Η ουσιαστική συζήτηση δεν αφορά το αν ένα pattern είναι παλιό ή σύγχρονο. Αφορά την κατεύθυνση των εξαρτήσεων, τα αρχιτεκτονικά όρια, τη συντηρησιμότητα, τη δυνατότητα δοκιμών και τους συμβιβασμούς που αποδεχόμαστε συνειδητά όταν σχεδιάζουμε μια εφαρμογή.

Αν επιλέγουμε Clean Architecture, πρέπει να γνωρίζουμε γιατί την επιλέγουμε εξαρχής.

1. Η Clean Architecture αφορά την κατεύθυνση των εξαρτήσεων

Η Clean Architecture δεν είναι απλώς μια δομή φακέλων με Domain, Application, Infrastructure και Presentation.

Σκοπός της είναι να διατηρεί τους επιχειρησιακούς κανόνες ανεξάρτητους από τις εξωτερικές τεχνικές λεπτομέρειες, όπως οι βάσεις δεδομένων, τα frameworks, τα user interfaces και οι υπηρεσίες υποδομής.