SqlDataSource vs ObjectDataSource

Question

Se una pagina Web richiede alcuni dati, perché non fare semplicemente una chiamata SQLDataSource a una stored procedure? Perché utilizzare ObjectDataSource per chiamare un oggetto business che chiama la stored procedure? Capisco che altre app (diciamo app per desktop) costruite sul framework .net possano accedere agli oggetti di business, ma cosa succede se l'applicazione sarà sempre solo un'app web?

Per essere più chiari:

Quando si dovrebbe utilizzare 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 attacco rapido. È veloce, è facile, funziona e ti dà i risultati di cui hai bisogno.

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

Come si suol dire - è possibile risolvere praticamente qualsiasi cosa in informatica da un ulteriore livello di indirezione (o astrazione) - lo stesso vale qui.

SICURO: si può andare direttamente al database, e sicuramente, all'inizio e per la prima iterazione, questo è probabilmente (o probabilmente) il modo più rapido. 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 la modifica in base alle esigenze dell'utente e del cliente Crescerà e abbastanza rapidamente, quella soluzione rapida e decaduta non sembra più così grande, in termini di sforzo.

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

Marc

Answer 2

Se si dispone di un livello aziendale che si sta utilizzando nei propri progetti, ObjectDataSource è la scelta naturale. Ciò si adatta bene a molte ORM e molte di esse offrono ulteriori vantaggi (convalida, annullamento, ecc.). Consente inoltre di accedere a qualsiasi altra proprietà & metodi che si hanno sui propri oggetti business - non solo i campi diretti di SQL. Questo può tornare utile quando si esegue l'associazione, poiché consente di associare semplicemente le proprietà al codice anziché dover scrivere molto codice.

Se si sta percorrendo questa rotta, la combinazione di SQLDataSource e ObjectDataSource può portare a confusione da parte del prossimo sviluppatore a raccogliere il proprio progetto. In questo caso, rimango con ObjectDataSource per la coerenza del codice.

Se non si dispone di un livello aziendale e si esegue direttamente SQL direttamente, utilizzare SQLDataSource. La mia preferenza personale è che tutto il codice SQL dovrebbe essere in un livello aziendale o di dati e poiché non utilizzo quasi mai SQLDataSource.

Answer 3

se si può avrai uno il codice livello aziendale nella stored procedure il suo meglio usare SQLDataSource

Answer 4

In teoria ObjectDataSource è meglio. Ma tutto dipende da quanto bene il modello dell'oggetto è scritto e documentato. Abbiamo esternalizzato un'azienda che utilizzava un generatore di codice personalizzato (che non ci avrebbero fornito) per produrre tutti i livelli. Si è rivelato un incubo apportare modifiche anche minime come l'aggiunta di una proprietà o la modifica di un tipo di campo. Ora sto rottamando praticamente tutto ciò che hanno fatto e semplicemente usando le stored procedure che hanno scritto.

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