Quali componenti del framework .Net dovrebbero evitare gli sviluppatori professionisti?

Question

. Net è una struttura enorme con alcune funzionalità che sembrano destinate ai principianti o diventano problematiche se sono coinvolte molte personalizzazioni. Quindi quali funzionalità disponibili nel framework .Net ritieni che gli sviluppatori professionali dovrebbero evitare e perché?

Ad esempio, .Net dispone di una procedura guidata per le funzioni di gestione utenti comuni. L'utilizzo di questa funzionalità è ritenuto appropriato per l'uso professionale o solo per un principiante?

Un componente/funzione/classe, ecc. Per risposta per favore quindi i voti sono specifici per un singolo articolo.

Answer 1

DataSet tipizzati
ASP.NET * Visualizza controlli
ASP.NET * DataSource Controlli

Answer 2

Thread.Abort

Ecco un eccellente articolo di Ian Griffiths su Why Thread.Abort is Evil e alcune alternative migliori.

Answer 3

Penso che in genere la maggior parte dei controlli/funzionalità che svolgono un sacco di lavoro "dietro le quinte" possono causare molti problemi. Nessun problema nell'utilizzare un GridView se quel layout è esattamente quello che vuoi - ma lo è molto raramente, e un Repeater è probabilmente una scelta migliore. UpdatePanels può farti risparmiare un sacco di lavoro se vuoi un tocco di ajaxy al tuo sito, ma rispetto a una chiamata jQuery AJAX loro - mi dispiace dirlo - fanno schifo. La procedura guidata utente che hai menzionato può essere davvero utile durante lo sviluppo, ma se la funzionalità dell'appartenenza è richiesta nel progetto dovrebbe essere costruita come parte integrante di essa.

Quindi, in sintesi: i programmatori professionisti dovrebbero eseguire autonomamente il lavoro e scrivere codice che soddisfi in modo specifico le esigenze dei propri clienti e prendere solo parti già pronte del .Net Framework quando ciò è di fatto esattamente ciò di cui hanno bisogno.

Answer 4

MS Ajax

jquery e altri framework js come prototipo, ecc, sono un'alternativa più leggera e flessibile. I controlli di MS Ajax possono sembrare grandi inizialmente, fino a quando non si ha realmente bisogno di un comportamento personalizzato fuori dall'ambito dei controlli.

Microsoft ha riconosciuto questo in una certa misura in quanto il jquery sarà associato alle prossime versioni di Visual Studio, con supporto intellisense.

Answer 5

LINQ to XML

XmlDocument/XPath è più facile da usare, se si vuole tipizzazione forte per analizzare l'utilizzo del documento xsd.exe o Xsd2Code.

EDIT

quale preferisci?

IEnumerable<XElement> partNos = 
    from item in purchaseOrder.Descendants("Item") 
    where (int) item.Element("Quantity") * 
     (decimal) item.Element("USPrice") > 100 
    orderby (string)item.Element("PartNumber") 
    select item; 

o, con XmlDocument e XPath

var nodes = myDocument.SelectNodes("//Item[USPrice * Quantity > 100]"); 

Answer 6

NET è un quadro enorme con alcune funzionalità che sembra indirizzare i principianti o diventa problematico se molto personalizzazione è coinvolto.

È il "sembra che colpisca i principianti", questo è il vero problema.

I set di dati digitati sono un ottimo esempio. VS offre una semplice interfaccia utente semplice a funzionalità che dovrebbero essere utilizzate solo dai principianti per creare applicazioni demo estremamente semplici e professionisti esperti che capiscano ogni sfumatura del modello di oggetto ADO.NET e quali set di dati tipizzati stiano effettivamente facendo. Nessuno tra questi due poli dovrebbe toccarlo, perché c'è un buon modo per apprendere ogni sfumatura del modello di oggetti ADO.NET e i set di dati digitati non lo sono.

Oppure prendere LINQ. È seducentemente facile scrivere codice LINQ senza avere una buona conoscenza di IEnumerable<T>. Ma non è così facile scrivere codice LINQ gestibile senza questa conoscenza.

Answer 7

Si può pensare a .NET come una cipolla con molti livelli. Ad esempio, .NET compact framework è un sottoinsieme di .NET completo. Inoltre ci sono strati "extra" in alto su .NET sotto forma di "Estensioni" che sono installazioni opzionali per nuove funzionalità che non sono ancora state rese parte di .NET. Un esempio di questo sarebbe quando Microsoft ha rilasciato ASP.NET 3.5 Extensions che ora è stato inserito in .NET 3.51.

Un altro modo di pensare a .NET è come un insieme di "librerie" che è possibile utilizzare. Ad esempio ci sono un set o routine per supportare RegEx. Se vuoi o hai bisogno di espressioni regolari, allora usi queste funzioni, altrimenti puoi semplicemente ignorarle. Funzioni matematiche per cose come la trigonometria o la sicurezza.

Quindi immagino che si riduca davvero a ciò di cui hai bisogno per la tua applicazione? Se stai facendo una programmazione scientifica potresti volere le funzioni trigonometriche. Un'app grafica richiede funzioni che l'applicazione console non richiederebbe. Le app Web probabilmente non hanno bisogno di usare le funzioni degli appunti, ecc.

Non credo proprio che in .NET esistano cattive API, solo programmatori che li usano in modi inappropriati.

Answer 8

Il servizio di remoting è in genere un buon modo per evitare, almeno se il tuo target è 3.0 o successivo e può quindi facilmente ospitare endpoint di messaggistica in-process.

Answer 9

C'è molto da evitare nella libreria WinForms.

Evita il DataBinding alla maggior parte dei controlli standard di WinForms. Ci sono molti bug in quell'area che porteranno a un sacco di grattarsi la testa. O almeno questa è stata la mia esperienza. NumericUpDown è un buon esempio di questo caos buggy.

Evitare anche i controlli standard di WinForms quando si ha a che fare con dataset di grandi dimensioni. Fanno molti copioni di dati e non riescono ad adattarsi bene ai grandi set di dati.

Evita ListView in modalità "Virtuale" poiché è pieno di bug.

In generale, consiglio di evitare WinForms. Se si dispone dell'opzione per WPF o almeno di acquistare una libreria di moduli di terze parti buona, ben supportata (e auspicabilmente meno complicata).