Utilizzo dei controlli SQLDataSource / DataBound in ASP.NET - Cattiva pratica?

Naviga le tue risposte
2

Quando si programma in ASP.NET, è possibile ottenere funzionalità molto veloci ed efficaci utilizzando i controlli DataBound ( GridView , FormView , ecc.) con un controllo SQLDataSource sulla pagina (a mio avviso, comunque - Potrei essere solo su quello). Ad esempio, utilizzo spesso questi tipi di controlli per creare funzionalità di ricerca di base, ad esempio la cronologia degli ordini in un'applicazione del carrello acquisti.

Tuttavia, questa risposta su SO mi ha fatto pensare: < strong> L'uso del controllo SQLDataSource è considerato una cattiva pratica? Non sono stato in grado di trovare alcuna risorsa online che sostenga questa affermazione, quindi ho pensato di chiedere qui.

La domanda su SO riguarda il calcolo del totale complessivo di una colonna in GridView . Gli svantaggi di SQLDataSource indicati dal rispondente (nei loro commenti) includono:

  • ASPX è la presentazione, non la logica aziendale.
  • Questa pratica ti fa ripetere SQL su ogni pagina che ne ha bisogno.
  • Quando apporti una modifica a un DB, devi modificare SQL in aspx.
  • Perché rende semplici le attività come la visualizzazione di un totale complessivo difficile.
  • La soluzione fornita calcola il totale complessivo in DataBound evento. Cosa succede se non usi il controllo con DataBound evento?
  • Perché non è testabile

Sono in qualche modo nuovo allo sviluppo di ASP.NET (proveniente da uno sfondo Java / C #), e volevo solo assicurarmi di non seguire il percorso sbagliato qui (usando il controllo SQLDataSource ).

    
posta jadarnel27 20.10.2011 - 17:39
fonte

2 risposte

3

Se stai imparando, utilizza sicuramente SqlDataSource . Lo svantaggio principale è il fatto che non ti permette di incapsulare nulla; la tua logica è direttamente sulla pagina e direttamente legata al / ai controllo / i. Oggigiorno anche l'associazione diretta dei dati è una cattiva pratica (la proprietà DataSource dovrebbe chiamare un servizio o repository o gateway o qualcosa di esterno all'interfaccia utente che restituisce una raccolta), ma va bene per un principiante che sta imparando le corde. Comprendi solo i limiti e ricorda che probabilmente non utilizzerai questo modo di fare le cose per qualsiasi progetto importante.

    
risposta data 20.10.2011 - 18:06
fonte
2

Ci sono un paio di considerazioni. Prima di tutto, la tecnologia lo consente, quindi perché non usarlo? Beh, ci possono essere molti motivi, ma quello che posso pensare è dall'architettura del sistema e dalla prospettiva di sicurezza. Il tuo server web è autorizzato ad avere una connessione diretta al tuo database (back-end?)? Se è così, è perfettamente ok usare i controlli di database, se no Dovrai creare un meccanismo di trasporto intermedio (ans quindi SqlDataSource è fuori ambito).

L'attivazione delle regole aziendali potrebbe essere un'altra. Ancora molti database vengono utilizzati per far rispettare le regole aziendali, se è così va tutto bene. Se devi attivare codice diffrente per applicare le tue regole aziendali, le cose potrebbero complicarsi e usare SqlDataSource potrebbe essere considerato una cattiva pratica.

L'argomento del test, non lo vedo davvero come problematico, si potrebbe dover scrivere una visione diversa per essere in grado di affermare il risultato, ma ciò non è neces- sariamente problematico.

Tuttavia scrivere codice SQL e business logic nelle pagine aspx è un problema e dovrebbe essere isolato in una libreria riutilizzabile.

    
risposta data 20.10.2011 - 18:20
fonte

Leggi altre domande sui tag

Come si scrive direttamente alla documentazione del punto senza sembrare trascurati e informali? Come si finisce con l'event-sourcing se si utilizza un approccio xDD?