Каких компонентов платформы .NET профессиональный разработчик должен обычно избегать?

MS Ajax

jquery и другие js-фреймворки, такие как прототип и т. Д., Являются более легкой и гибкой альтернативой. Элементы управления MS Ajax поначалу могут показаться великолепными, пока вам действительно не понадобится настраиваемое поведение вне области действия элементов управления.

Сами Microsoft признали это в некоторой степени в том смысле, что jquery будет поставляться в будущих версиях Visual Studio с intellisense. поддержка.

Я думаю, что в большинстве случаев большинство элементов управления / функций, которые выполняют большую часть работы "за кулисами", могут вызвать много проблем , Нет проблем с использованием GridView, если этот макет точно , что вы хотите - но это очень редко, и Repeater, вероятно, лучший выбор. UpdatePanels может сэкономить вам много работы, если вы хотите, чтобы ваш сайт чувствовал ajaxy, но по сравнению с вызовом jQuery AJAX они - извините, скажем так - отстой. Упомянутый вами мастер пользователя может быть очень полезен во время разработки, но если в проекте требуется функциональность членства, он должен быть встроен как его неотъемлемая часть.

Итак, подведем итог: профессиональные программисты должны выполнять свою работу самостоятельно и писать код, который специально удовлетворяет потребности своих клиентов, и принимает только готовые части.

Thread.Abort

Вот отличная статья Иена Гриффитса о Почему Thread.Abort является злом и некоторые лучшие альтернативы.

Типизированные наборы данных
ASP.NET * Просмотр элементов управления
Элементы управления источниками данных ASP.NET *

Как правило, удаленного взаимодействия лучше избегать, по крайней мере, если вы нацеливаетесь на 3.0 или выше и поэтому можете легко принять конечные точки обмена сообщениями находятся в процессе.

Linq To XML

XmlDocument / Xpath проще в использовании, если вы хотите строгую типизацию для анализа вашего документа xsd.exe или Xsd2Code .

РЕДАКТИРОВАТЬ

, какой вариант вы предпочитаете?

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;

или с XmlDocument и XPath

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

.Net - это огромный фреймворк с некоторыми функциональными возможностями, который предназначен для начинающих или становится проблематичным, если требуется много настроек.

«Похоже, нацеленность на начинающих» - вот настоящая проблема.

Типизированные наборы данных являются отличным примером. VS предоставляет приятный простой пользовательский интерфейс для функций, которые должны использовать только начинающие разработчики, создающие чрезвычайно простые демонстрационные приложения, и опытные профессионалы, которые понимают каждый нюанс объектной модели ADO.NET и то, что фактически делают типизированные наборы данных. Никто между этими двумя полюсами не должен касаться этого, потому что есть хороший способ изучить каждый нюанс объектной модели ADO.NET, а типизированные наборы данных не так ли.

Или возьмите LINQ. Это' Соблазнительно легко писать код LINQ без хорошего понимания IEnumerable . Но не так легко написать поддерживаемый код LINQ без этого знания.

Вы можете думать о .NET как о луке со многими слоями. Например, компактный каркас .NET является подмножеством полного .NET. Кроме того, в .NET есть «дополнительные» слои в форме «Расширений», которые являются необязательными установками для новых функций, которые еще не стали частью самой .NET. Примером этого может послужить то, что Microsoft выпустила ASP.NET 3.5 Extensions , который теперь свернут в .NET 3.51.

Другой способ представить себе .NET - это набор «библиотек», которые вы можете использовать. Например, есть набор или подпрограммы для поддержки RegEx. Если вы хотите или нуждаетесь в регулярных выражениях, то вы используете эти функции, если не можете просто игнорировать их. Симиллярные функции для таких вещей, как тригонометрия или безопасность.

Так что, думаю, все сводится к тому, что вам нужно для вашего приложения? Если вы занимаетесь научным программированием, вам вполне могут потребоваться триггерные функции. Для графического приложения потребуются функции, которых нет в консольном приложении. Веб-приложениям, вероятно, не нужно использовать функции буфера обмена и т. Д.

Я действительно не думаю, что в .NET есть какие-то плохие API, просто программисты, которые используют их ненадлежащим образом.

В библиотеке WinForms есть многое, чего следует избегать.

Избегайте привязки данных к большинству стандартных элементов управления WinForms. В этой области много ошибок, которые могут привести к большому количеству царапин на голове. Или, по крайней мере, это был мой опыт. NumericUpDown является хорошим примером этой ошибочной путаницы.

Также избегайте стандартных элементов управления WinForms при работе с большими наборами данных. Они много копируют данные и плохо справляются с большими наборами данных.

Избегайте использования ListView в «виртуальном» режиме, поскольку он полон ошибок.

В общем, я просто рекомендую держаться подальше от WinForms. Если у вас есть возможность, перейдите на WPF или, по крайней мере, купите хорошую, хорошо поддерживаемую (и, надеюсь, менее глючную) библиотеку сторонних форм.