Crei classi per gestire le "entità" per le app basate sui dati?

Question

Sono un principiante e quando si scherza con la creazione di applicazioni di database ho sempre creato i miei moduli e messo tutto il codice e i collegamenti. Invece di avere matrici ed elenchi che contenevano informazioni, ho apportato direttamente modifiche al database.

Ora che mi sono leggermente evoluto, supponiamo di aver venduto widget ai clienti e di conservare le informazioni sulle vendite in un database. Se stavo scrivendo un programma per accedere al database non vorrei creare una classe di tipo "Cliente" e "Widget" per lavorare con tali entità?

Se sbaglio, qual è l'approccio appropriato alla programmazione delle applicazioni di database?

Answer 1

Sì.

Vuoi dare un'occhiata alla n-tier .

Fondamentalmente, consenti al tuo front-end (livello di presentazione) di accedere solo alla tua biblioteca di classe (livello aziendale). La tua biblioteca di classe accede quindi al tuo database.

Questo ti offre una soluzione meno strettamente accoppiata e consente un codice più gestibile. Inoltre, introducendo i livelli, è possibile apportare modifiche al proprio DB senza la necessità di riscrivere il codice nel frontend, purché non sia necessario modificare l'interfaccia con il livello aziendale.

Per quanto riguarda l'associazione, se si utilizza Visual Studio Windows Forms (dal 2005 in poi) dovresti essere in grado di fornirci un bindingSource che puoi quindi utilizzare per associare i tuoi controlli. Se si utilizza ASP.NET, il controllo deve essere associato a un elenco di oggetti senza problemi.

Per ASP.Net ObjectDataSource potrebbe valere la pena di esaminare . Non l'ho usato da solo, ma ci sono molti campioni sul web. Prova qui o qui .

Answer 2

Sì.

Desideri esaminare attentamente Mappatura relazionale oggetto .

Le entità aziendali del mondo reale sono modellate da oggetti associati a tabelle relazionali.

Answer 3

Non si desidera che il proprio livello di presentazione dipenda direttamente dalla struttura del database; il problema è che se la struttura del database cambia, il livello di presentazione deve cambiare e, a lungo termine, tende a causare problemi. Inoltre, ci sono problemi di sicurezza associati all'avere il tuo livello di presentazione interagire direttamente con il tuo database.

L'analogia approssimativa qui è ai mercati; quando vai al negozio per comprare una pagnotta, non hai bisogno di sapere come coltivare il grano; tutto quello che devi sapere è che hai soldi e loro hanno pane e che scambieranno una certa quantità di pane con una certa quantità di denaro. Non hai bisogno di sapere in quale periodo dell'anno per piantare il grano, o come rimuovere la paglia, o qualcosa del genere, perché lo strato di supporto si prende cura di quello per te. Allo stesso modo, l'agricoltore non ha bisogno di sapere come vendere il pane a un intero gruppo di persone, o anche come fare il pane; tutto quello che deve fare è sapere come coltivare il grano.

La moderna filosofia del design consiglia di utilizzare un livello intermedio per interagire tra il livello di presentazione e il livello del database; qui è dove metti la tua logica aziendale. Ad esempio, supponiamo che tu stia vendendo widget sul tuo sito. Invece di fare in modo che il tuo codice di presentazione richieda il database per i widget e lo visualizzi, hai un oggetto business che gestisce i tuoi widget. In questo modo, l'oggetto business deve sapere qual è la struttura del database, ma il livello di presentazione deve solo sapere come chiedere all'oggetto business un elenco di widget da visualizzare. Ancora più importante, nell'oggetto business è possibile inserire le regole che devono essere invocate quando accadono determinate cose. Pertanto, invece del livello di presentazione che apporta direttamente modifiche al database per inventario e ordini quando viene effettuato un ordine, l'oggetto business sa come apportare le modifiche e quali tabelle modificare quando il livello di presentazione richiede che si verifichi una vendita.

In questo modo, separi la visualizzazione delle tue informazioni dalla persistenza e dalla logica alla base del sito web. Ciò che è coinvolto è una buona pianificazione; in particolare, devi capire cosa farà il tuo sito web in un dato momento e cosa significa in termini di interfacce che forniranno i tuoi oggetti aziendali. Quindi implementate i vostri oggetti business in base a tali requisiti; quegli oggetti business sono dove metti la conoscenza della struttura del database e della tua specifica logica aziendale ("quando succede A, fai B e poi C", ecc.).

All'inizio sembra un sacco di lavoro extra, ma ne vale davvero la pena.