Origine dati oggetto o code-behind: qual è il migliore?

Question

So che è un argomento che può sollevare un sacco di discussioni, ma mi piacerebbe sapere cosa pensano le persone i vari pro e contro dell'utilizzo di Object Datasources. Sto facendo un progetto in questo momento con un altro programmatore che ha esperienza e livello di comfort sono tutti radicati nel classico ASP, e non sono sicuro di che cosa sta andando a
a) portare a termine il lavoro rapidamente b) portare a termine il lavoro con un minimo di confusione

Abbiamo un bel livello di repository con oggetti di dominio in grado di auto-validazione, quindi sono in atto i metodi per eseguire il binding ODS o il binding code-behind.

Non mi piace l'ODS per la maggior parte delle ovvie ragioni, ma se mi salvasse dall'avere a mano il codice di paging/ordinamento/selezione/inserimento/aggiornamento/eliminazione di scenari, allora può essere davvero così brutto?

Answer 1

Le origini dati oggetto sono utili per i progetti di piccole dimensioni, ma non si adattano in modo ottimale mentre si incorporano le informazioni a livello di dati nel livello dell'interfaccia utente dell'applicazione. Ti suggerirei di usarli solo per applicazioni molto piccole e roba da test antigraffio. Se prendi una decisione progettuale per usarli, preparati a combattere i problemi di ridimensionamento e manutenzione in futuro.

Answer 2

Personalmente, penso che dipenda dal progetto. Se si tratta di una piccola applicazione CRUD con un paio di pagine, il collegamento a un'origine dati di un oggetto sarà probabilmente rapido, semplice e avrà poche conseguenze.

Se si tratta di un'applicazione su larga scala con esigenze personalizzate, potrebbe risultare frustrante provare a fare in modo che un'origine dati dell'oggetto soddisfi le esigenze specifiche.

Answer 3

La sempre più familiare familiarità con il framework ADO.NET sottostante utilizzato, sempre meno ci si affiderà ai controlli dell'origine dati inclusi in Visual Studio. Li ho usati religiosamente nei primi progetti .NET su cui ho lavorato, ma ho scoperto rapidamente che sarebbe stato molto meglio usare solo i fondamenti della connessione e del recupero dei dati su un database piuttosto che affidarmi a .NET per renderlo miglior tentativo di farlo per me.

Li guardo più o meno come ruote di allenamento per familiarizzare con il ciclo di vita della documentazione più o meno.

Answer 4

A mio parere entrambi hanno il loro posto, i loro punti di forza e di debolezza. Il tempo risparmiato nella codifica degli elementi che hai citato, in particolare il paging e l'ordinamento, sono di grande aiuto, ma se vuoi fare qualcosa di interessante a distanza con loro, diventano presto dolori da affrontare.

Uso ODS quando i dati verranno utilizzati esclusivamente per la visualizzazione. Schiaffo in una griglia di dati, un ODS, e il gioco è fatto. Ma se questi dati devono essere manipolati in qualche modo, rimango lontano da tutti i pezzi costruiti, senza griglie, senza ODS.

Answer 5

Penso che in generale, il codice sottostante sia più utile perché fornisce una posizione centrale per la personalizzazione delle connessioni del livello dati. Finché dividi l'azione in diversi livelli, il codice dietro può essere molto scalabile.

Le origini dati oggetto personalizzate, d'altra parte, sono molto utili perché consentono il binding intrinseco con il controllo GridView. Il set di dati fornito dall'origine dati dell'oggetto personalizzato consente un facile ordinamento e impaginazione. L'oggetto personalizzato fornisce anche una posizione centrale per l'accesso al livello dati.

Answer 6

Il più grande vantaggio di DataSourceControls è che allontanano diverse preoccupazioni circa il ciclo di vita .NET fornendo supporto per CRUD completo e le espressioni di associazione bidirezionale, vale a dire.<% # Bind ("FirstName")%> (tuttavia l'associazione dati bidirezionale fa schifo, quindi probabilmente non ti stai perdendo nulla). Come modello di progettazione, è una buona idea con un'implementazione mediocre (molto simile a WebForms stesso).

Se disabiliti viewstate e ti trovi a cercare di capire il motivo per cui i tuoi postback non vengono gestiti, o finisci per dover chiamare DataBind() in diversi punti, le origini dati possono portare via parte del mal di testa, perché il DataBoundControls è abbastanza intelligente da sapere quando hanno bisogno di dati e lo richiedono semplicemente dall'origine dati. Nessuna chiamata DataBind() necessaria.

DataSources fornisce anche un modo piacevole per gestire l'ordinamento, il filtraggio e l'impaginazione. La maggior parte degli sviluppatori, quando usano code-behind, di solito non eseguono l'impaginazione e alla fine restituiscono enormi set di risultati dal database.

Lo svantaggio delle origini dati è che non ci sono state molte buone implementazioni. Di solito si finisce per legare l'interfaccia utente Web all'implementazione di persistenza (ad esempio SqlDataSource, LinqDataSource, ecc.) O si finisce con l'uso di ObjectDataSource, che fa schifo perché è così limitato, richiede di scrivere i nomi delle classi e dei metodi nell'ASPX e usa la riflessione in qualche modo in modo inefficiente. Per questo motivo, non è utile per le persone che utilizzano l'iniezione di dipendenza o le classi DAO statiche. È una classe piuttosto mal concepita e sembra quasi un ripensamento della SM.

Personalmente preferirei utilizzare DataSource AND code-behind. Utilizzare un DataSource per rimuovere il mal di testa lifecycle/viewstate e quindi fornire un evento/delegato "Select" nel code-behind. Sfortunatamente, ObjectDataSource può utilizzare solo la reflection, tuttavia è possibile scrivere facilmente la propria implementazione. Ne ho uno mio ma non è pubblico. Tuttavia prima ho scritto che ho usato questo, che costituisce per alcune delle inadeguatezze di ObjectDataSource:

http://mikeoff.blogspot.com/2006/06/objectdatasource-working-alternative.html

Answer 7

ObjectDataSource come qualsiasi altro xxxDatasource in WebForms è il coordinatore tra il vostro livello di business in applicazioni di grandi dimensioni (o lo strato di accesso ai dati su quelli più piccoli) e i controlli stessi.

Fornisce solo dati e altre funzionalità alla parte visiva dell'applicazione, l'interfaccia utente guidata dalle visualizzazioni nel data store.

Le persone dovrebbero vedere questi comandi come richieste e risposte per gli elementi dell'interfaccia utente e interromperne l'abuso o scartarli completamente. Non sono il DAL, non sono malvagi, sono solo connessioni ai tuoi dati che controlli sanno come parlare in modo molto efficiente.

Se si dispone ad esempio di una griglia di dati che varia l'origine in base a una decisione, è necessario configurare due ObjectDatasources e tale decisione deve risiedere nella pagina, non in ObjectDatasource. Questo è il modo preferito per usarli ed evitare i problemi che le persone cercano di riferirsi ad altre risposte.