Quels composants du framework .Net devraient normalement être évités par un développeur professionnel?

Question

.Net est un énorme framework avec certaines fonctionnalités qui semblent cibler les débutants ou qui deviennent problématiques si beaucoup de personnalisation est impliquée. Alors, quelles fonctions du framework .Net pensez-vous que les développeurs professionnels devraient éviter et pourquoi?

Par exemple, .Net dispose d'un assistant pour les fonctions de gestion des utilisateurs courantes. Est-ce que l'utilisation de cette fonctionnalité est considérée appropriée pour un usage professionnel ou pour un débutant seulement?

Un composant/fonction/classe, etc. par réponse s'il vous plaît donc les votes sont spécifiques à un seul article.

Answer 1

typées
DataSets ASP.NET * Voir Contrôle
ASP.NET * DataSource Controls

Answer 2

Thread.Abort

Voici un excellent article de Ian Griffiths à propos de Why Thread.Abort is Evil et de meilleures alternatives.

Answer 3

Je pense généralement que la plupart des commandes/fonctions qui font beaucoup de travail dans les coulisses peuvent causer beaucoup de problèmes. Pas de problème en utilisant un GridView si cette disposition est exactement ce que vous voulez - mais c'est très rarement, et un répéteur est probablement un meilleur choix. UpdatePanels peut vous épargner beaucoup de travail si vous voulez une sensation d'ajax sur votre site, mais comparé à un appel jQuery AJAX ils - désolé de le dire - sucent. L'assistant utilisateur que vous mentionnez peut être très utile lors du développement, mais si une fonctionnalité d'appartenance est requise dans le projet, elle doit être intégrée en tant que partie intégrante. Donc, en résumé: Les programmeurs professionnels devraient faire le travail eux-mêmes et écrire du code qui répond spécifiquement aux besoins de leurs clients, et ne prendre en compte que les parties déjà faites du Framework .Net quand c'est exactement ce dont ils ont besoin.

Answer 4

MS Ajax

jquery, et d'autres cadres de js comme prototype, etc., sont une alternative plus légère et flexible. Les contrôles MS Ajax peuvent sembler excellents au départ, jusqu'à ce que vous ayez vraiment besoin d'un comportement personnalisé hors de la portée des contrôles.

Microsoft a lui-même reconnu cela dans une certaine mesure en ce sens que jquery sera livré avec les prochaines versions de Visual Studio, avec le support d'IntelliSense.

Answer 5

LINQ to XML

XmlDocument/XPath est plus facile à utiliser, si vous voulez taper fort pour analyser votre utilisation de documents xsd.exe ou Xsd2Code.

EDIT

qui préférez-vous?

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; 

ou, avec XmlDocument et XPath

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

Answer 6

.Net est un énorme cadre avec une fonctionnalité qui semble cibler les débutants ou devient problématique si beaucoup de personnalisation est impliqué.

C'est le «semble cibler les débutants» qui est le vrai problème.

Les ensembles de données typés sont un bon exemple. VS fournit une interface utilisateur conviviale simple qui ne doit être utilisée que par les débutants qui créent des applications de démonstration extrêmement simples et des professionnels expérimentés qui comprennent toutes les nuances du modèle d'objet ADO.NET et ce que font réellement les ensembles de données. Personne entre ces deux pôles ne devrait y toucher, car il y a un bon moyen d'apprendre toutes les nuances du modèle d'objet ADO.NET et les ensembles de données typés ne le sont pas.

Ou prendre LINQ. Il est séduisant d'écrire du code LINQ sans avoir une bonne compréhension de IEnumerable<T>. Mais ce n'est pas si facile d'écrire du code LINQ maintenable sans cette connaissance.

Answer 7

Vous pouvez penser à .NET comme un oignon avec plusieurs couches. Par exemple, le .NET compact framework est un sous-ensemble de .NET complet. En outre, il existe des couches "supplémentaires" sur .NET sous la forme de "Extensions" qui sont des installations facultatives pour les nouvelles fonctionnalités qui n'ont pas encore été intégrées à .NET proprement dit. Un exemple de ceci serait quand Microsoft a publié ASP.NET 3.5 Extensions qui a maintenant été roulé dans .NET 3.51.

Une autre façon de penser à .NET est un ensemble de "bibliothèques" que vous pouvez utiliser. Par exemple, il existe un ensemble ou des routines pour supporter RegEx. Si vous voulez ou avez besoin d'expressions régulières, vous utilisez ces fonctions, sinon vous pouvez simplement les ignorer. Fonctions SImilary pour des choses comme la trigonométrie ou la sécurité.

Donc je suppose que cela se résume vraiment à ce dont vous avez besoin pour votre application? Si vous faites de la programmation scientifique, vous voudrez peut-être utiliser les fonctions trigonométriques. Une application graphique nécessitera des fonctions qu'une application console ne le ferait pas. Les applications Web n'ont probablement pas besoin d'utiliser les fonctions du presse-papier, etc.

Je ne pense vraiment pas qu'il y ait de mauvaises API dans .NET, juste des programmeurs qui les utilisent de manière inappropriée.

Answer 8

La communication à distance est généralement une bonne solution à éviter, du moins si vous ciblez la version 3.0 ou supérieure et pouvez donc facilement héberger des points de terminaison de messagerie en cours de traitement.

Answer 9

Il y a beaucoup à éviter dans la bibliothèque WinForms.

Évitez la liaison de données avec la plupart des contrôles WinForms standard. Il y a beaucoup de bugs dans cette zone qui vont conduire à beaucoup de grattage de la tête. Ou du moins cela a été mon expérience. NumericUpDown est un bon exemple de ce bazar buggé.

Évitez également les contrôles WinForms standard lorsque vous traitez de grands ensembles de données. Ils font beaucoup de copies de données et ne peuvent pas traiter correctement les grands ensembles de données.

Évitez ListView en mode "virtuel" car il est plein de bugs.

En général, je recommande juste de rester loin de WinForms. Si vous avez l'option aller pour WPF ou au moins acheter une bonne bibliothèque de formulaires tiers bien pris en charge (et, espérons-le, moins buggé).