Il modo più comune che ho visto di salvare un'entità in un database è attraverso una classe in un livello di business / servizio. Ad esempio, quando aggiungi una nuova entità chiamata User :
User user = new User();
user.Name = "Foo";
UserService userService = new UserService();
userService.Add(user);
Funziona e gli oggetti vengono utilizzati, ma ritengo che lo stile sia inclinato verso il lato procedurale. Di solito, la classe UserService contiene principalmente metodi per interagire con il database. Potresti quasi rendere statica la UserService class e quindi non sarà più considerata come un oggetto.
In un modo puramente orientato agli oggetti, sento che il codice sarebbe simile a questo:
User user = new User();
user.Name = "Foo";
user.Add();
La mia domanda non riguarda dettagli specifici dell'implementazione, ma la progettazione orientata agli oggetti in generale. Usare classi come nell'esempio UserService indica un modo procedurale di codifica? Se sì, quale potrebbe essere un approccio migliore orientato agli oggetti?
Un esempio del framework .NET che ritengo sia più orientato agli oggetti è SqlConnection . Come apriamo una connessione? Esiste una classe SqlService da cui è possibile chiamare sqlService.Open(sqlConnection) ? No, ma viene eseguito dall'oggetto SqlConnection stesso: sqlConnection.Open() .
Ora il metodo Open può utilizzare altre classi a sua volta, ma ciò che è interessante per me è che è esposto sulla classe SqlConnection stessa, proprio come il metodo Add è esposto nella classe User nel secondo frammento sopra.