2009-10-25 8 views
8

Sono in procinto di apprendere ASP.NET. Ho comprato alcuni libri sull'argomento. Tutti suggeriscono che l'utilizzo dei controlli dell'origine dati, come ObjectDataSource/SqlDataSource ecc. È la strada da percorrere. Ora, sicuramente non sono un esperto in materia, tutt'altro. ma ho la netta sensazione che questi siano strumenti giocattolo. Ho difficoltà a credere che queste classi verrebbero utilizzate in un mondo reale, un'applicazione di livello enterprise. Ho ragione? Oppure queste classi hanno effettivamente un posto nelle applicazioni web su larga scala?È davvero professionale utilizzare i controlli dell'origine dati in ASP.NET?

Grazie, Avi

+0

Bene, vedo che le opinioni sono contrastanti. Immagino che ci proverò, solo così ottengo una prima impressione, se non altro. Ho la sensazione che alla fine lo abbandonerò. Venendo da uno sfondo di sviluppo lato server, trovo molto difficile mettere qualsiasi logica nel livello dell'interfaccia utente, anche se è solo 'dichiarativo'. Grazie ragazzi :) –

risposta

10

Questi controlli hanno guadagnato una cattiva reputazione a causa di sviluppatori inesperti che li utilizzano senza capirle, e sviluppatori professionisti guardando verso il basso su di loro come un risultato. Il miglior consiglio che posso darti è che un professionista userà qualsiasi strumento sia il più appropriato e che faccia il lavoro senza intralciarlo. Se questi strumenti fanno il lavoro per te, allora dovresti usarli e non lasciare che la gente ti metta giù per questo.

1

Sono ottimi per compilare un controllo associato se la query è semplice, come un elenco a discesa di categorie. Sono piuttosto dolorosi per fare ricerche personalizzate o simili. Valuta il tuo approccio caso per caso.

0

Personalmente preferisco telegrafare da solo. È piuttosto semplice eseguire stored proc per recuperare i dati e assegnarli ai controlli di inserimento dati senza utilizzare l'associazione dati. È anche facile prendere i dati modificati e aggiungerli, aggiornarli o eliminarli secondo necessità. Le classi dell'origine dati aggiungono quello che mi sembra un livello aggiuntivo non necessario. Se fossero significativamente più semplici di come lo faccio potrei dare loro una possibilità, ma mi sembrano abbastanza complessi. E, anche se non ho alcun dato di riferimento per dimostrarlo, sembra che debbano essere meno efficienti.

1

non essere più d'accordo - mescolando in roba connessione al database con l'HTML, potenzialmente logica di business, ecc, ecc è una pessima idea nel mondo moderno di unit testing, DDD, TDD, ecc

Ci saranno essere le situazioni in cui sono appropriate (forse la più semplice delle attività di reporting che devono essere eseguite in fretta, mockup) ma in generale evitarle.

2

Penso che si possa sostenere che l'uso di ObjectDataSource sia ragionevole, presumendo che stia effettivamente parlando con un vero livello intermedio di oggetti. Soprattutto se gli sviluppatori estendono l'ODS per giocare con il loro livello intermedio.

Gli altri ti spezzeranno le dita (seconda infrazione) nel mio negozio.

2

La prima cosa che devi realizzare su ASP.NET è che, tutto ciò che riguarda i controlli del server e il paradigma delle webform in generale, non funzionerà mai come Response.Write(). L'intera idea delle forme web è quella di ottenere il più rapidamente possibile dal punto A al punto B. Quindi, prima di scegliere i webforms dovresti chiederti, è questa la struttura migliore per la mia app? Per i siti Web ad alto traffico e/o se ti interessano molto i modelli di progettazione, sceglierei MVC senza dubbio.

Ora, se si scelgono webform, quindi consiglio vivamente di utilizzare i controlli dell'origine dati. Ti renderà la vita più facile. Non so come si definiscono le applicazioni aziendali , ma i controlli dell'origine dati possono ottenere grandi risultati. Ti consiglio di esaminare LinqDataSource, EntityDataSource, il nuovo DomainDataSource, il nuovo QueryExtender e come funzionano con qualsiasi sorgente IQueryable.

3

Sono d'accordo con Wyatt e ho pensato di aggiungere un po 'più di informazioni.Il problema con tutti gli oggetti di origine dati (diversi da ObjectDataSource) è che non è possibile suddividere l'applicazione in livelli logici (ad es. UI, business logic, accesso ai dati). Stai inserendo tutto il codice di accesso ai dati nell'interfaccia utente e ciò è molto negativo da una vista architettonica del progetto.

+0

Grazie per la risposta Jason. Ho solo una domanda su qualcosa nel tuo commento. Hai menzionato che tutti i controlli dell'origine dati potrebbero effettivamente essere problematici in un'applicazione multilivello, ad eccezione di ObjectDataSource. Stai dicendo che questo controllo specifico può effettivamente essere utilizzato in un'app a più livelli? E se è possibile, è consigliabile utilizzarlo in tali scenari? Grazie per il vostro tempo –

+0

ObjectDataSource può essere utilizzato in un'applicazione multilivello, poiché è possibile "collegarlo" agli oggetti nel proprio livello aziendale. Potrebbe sicuramente essere usato come un modo per accedere a tutte le funzionalità di un'origine dati associata con un'applicazione multilivello. –

1

La dichiarazione che un controllo dell'origine dati inserisce il codice direttamente nel modulo non è necessariamente un'istruzione corretta. Generalmente si dispone di una classe controller e si associa il controllo dell'origine dati al metodo del controller.

Hai ancora il livello intermedio e qualsiasi altra cosa. Come affermato da un manifesto, di solito sono gli sviluppatori con esperienza che rovinano il motivo per cui questi controller sono preziosi. Gestiscono tutti gli impianti idraulici per la pagina e si dispone ancora di separazione tra l'interfaccia utente e il livello intermedio (controller).

Ma dipende anche se si è più di un programmatore oop che preferisce gli oggetti domini opposti ai set di dati.

Problemi correlati