SqlDataSource vs ObjectDataSource

Question

Se una pagina Web necessita di alcuni dati, perché non fare in modo che SQLDataSource chiami una procedura memorizzata? Perché utilizzare un ObjectDataSource per chiamare un oggetto business che quindi chiama la procedura memorizzata? Comprendo che altre app (diciamo app desktop) costruite sul framework .net possono accedere agli oggetti business, ma cosa succede se l'applicazione sarà sempre solo un'app Web?

Per essere più chiari:

Quando si dovrebbe usare un SqlDataSource o ObjectDataSource ?

Come si motiva la scelta?

Answer 1

Avere solo un SQLDataSource è perfettamente valido, se è solo una demo, un prototipo o un hack rapido. È veloce, è facile, funziona e ti dà i risultati di cui hai bisogno.

Tuttavia, quando un'app è progettata e costruita a lungo termine e prevede che le cose (requisiti, desideri dei clienti, eventualmente lo schema del database) possano cambiare, allora potrebbe avere molto più senso introdurre un " business " layer: modella i tuoi oggetti business come oggetti, quindi fornisci una mappatura dal database sottostante a tali oggetti business.

Come dice il proverbio - puoi risolvere praticamente qualsiasi cosa nell'informatica con un ulteriore livello di indiretta (o astrazione) - lo stesso vale qui.

SICURO: puoi andare direttamente al database e sicuramente, all'inizio e per la prima iterazione, è probabilmente (o probabilmente) il modo più veloce. Ma a lungo termine, quando un'app è costruita per durare, di solito è un modo rapido e sporco : i costi di manutenzione, i costi di manutenzione, i costi e gli sforzi necessari per cambiare in base a le esigenze di te e dei tuoi clienti cresceranno e abbastanza rapidamente, quella soluzione rapida e sporca non sembra più così grande, in termini di sforzo.

Quindi, per riassumere il mio punto: sì, inizialmente, usare un'origine dati SQL diretta potrebbe essere più veloce e più facile - quindi usalo quando questo è il punto importante: per fare le cose per una demo veloce, una prova di concetto app di stile. Ma a lungo termine, quando guardi la durata di vita di un'app, di solito vale la pena investire un po 'più di sforzo (progettazione e codifica) per aggiungere questo livello di astrazione in modo che le tue pagine web non dipendano direttamente dai dettagli di il database sottostante.

Marc

Answer 2

Se hai un livello aziendale che stai utilizzando nei tuoi progetti, ObjectDataSource è la scelta naturale. Ciò si adatta bene a molti ORM e molti di essi offrono ulteriori vantaggi (convalida, annullamento, ecc.). Ti consente anche di accedere a qualsiasi altra proprietà & amp; metodi che hai sugli oggetti business, non solo sui campi SQL diretti. Questo può tornare molto utile quando si esegue l'associazione, poiché consente di associare solo le proprietà nel markup invece di dover scrivere molto codice dietro.

Se stai seguendo questa strada, mescolare SQLDataSource e ObjectDataSource può creare confusione da parte dello sviluppatore successivo per ritirare il tuo progetto. In questo caso, mi attengo a ObjectDataSource per la coerenza del codice.

Se non si dispone di un livello aziendale e si sta semplicemente colpendo direttamente SQL, utilizzare SQLDataSource. La mia preferenza personale è che tutto il tuo codice SQL dovrebbe trovarsi in un livello aziendale o di dati, e per il fatto che non uso quasi mai SQLDataSource.

Answer 3

se è possibile applicare il codice del livello aziendale nella procedura memorizzata è meglio usare SQLDataSource

Answer 4

In teoria objectdatasource è meglio. Ma tutto dipende da quanto bene il modello a oggetti viene scritto e documentato. Abbiamo esternalizzato un'azienda che ha utilizzato un generatore di codice personalizzato (che non ci fornirebbe) per produrre tutti i livelli. Si è rivelato un incubo apportare anche piccole modifiche come l'aggiunta di una proprietà o la modifica di un tipo di campo. Ora sto demolendo praticamente tutto quello che hanno fatto e usando solo le procedure memorizzate che hanno scritto.

Il mio obiettivo a lungo termine è di riscrivere l'applicazione da zero utilizzando uno strumento di modellazione commerciale e amp; generatore di codici. Se hai intenzione di utilizzare objectdatasource ti consiglio vivamente di trovare un buon strumento di modellazione che includa un generatore di codice flessibile.