¿Qué componentes del framework .Net debería evitar un desarrollador profesional?

Question

.Net es un gran marco con algunas funcionalidades que parecen apuntar a los principiantes o se vuelven problemáticas si se trata de mucha personalización. Entonces, ¿qué funcionalidad disponible en el framework .Net considera que los desarrolladores profesionales deberían evitar y por qué?

Por ejemplo, .Net tiene un asistente para funciones comunes de administración de usuarios. ¿Está utilizando esta funcionalidad considerada apropiada para uso profesional o solo para principiantes?

Un componente/función/clase, etc. por respuesta por favor por lo que los votos son específicos para un solo artículo.

Answer 1

conjuntos de datos con tipo
ASP.NET * Ver Controles
ASP.NET * Controles de origen de datos

Answer 2

Thread.Abort

He aquí un excelente artículo de Ian Griffiths acerca Why Thread.Abort is Evil y algunas alternativas mejores.

Answer 3

Creo que, en general, la mayoría de los controles/funciones que hacen mucho trabajo "entre bastidores" pueden causar muchos problemas. No hay problema con el uso de un GridView si ese diseño es exactamente lo que desea, pero es muy raro, y un repetidor es probablemente una mejor opción. UpdatePanels puede ahorrarle mucho trabajo si desea una sensación de Ajax en su sitio, pero en comparación con una llamada jQuery AJAX, lo siento decirlo, apestan. El asistente de usuario que mencione puede ser realmente útil durante el desarrollo, pero si se requiere la funcionalidad de membresía en el proyecto, debe construirse como una parte integrada del mismo.

Por lo tanto, en resumen: los programadores profesionales deben hacer el trabajo ellos mismos y escribir código que satisfaga específicamente las necesidades de sus clientes, y solo tomar partes listas de .Net Framework cuando de hecho es exactamente lo que necesitan.

Answer 4

MS Ajax

jQuery, y otros marcos js como prototipo, etc., son una alternativa más ligera y flexible. Los controles MS Ajax pueden parecer geniales inicialmente, hasta que realmente necesite un comportamiento personalizado fuera del alcance de los controles.

Microsoft mismo ha reconocido esto hasta cierto punto en que jquery se incluirá con las próximas versiones de Visual Studio, con soporte intellisense.

Answer 5

LINQ to XML

XmlDocument/XPath es más fácil de usar, si quieres inflexible de tipos para analizar su uso o documento xsd.exeXsd2Code.

EDITAR

cuál prefiere?

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 y XPath

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

Answer 6

.Net es una enorme estructura con algunas funciones que parece apuntar a los principiantes o se vuelve problemático si tanto la personalización está involucrado.

Es el "problema para los principiantes" ese es el problema real.

Los conjuntos de datos mecanografiados son un gran ejemplo. VS proporciona una interfaz de usuario simple y agradable a la funcionalidad que solo deben usar los principiantes de rango que crean aplicaciones de demostración extremadamente simples y profesionales experimentados que entienden todos los matices del modelo de objetos ADO.NET y lo que realmente hacen los conjuntos de datos tipados. Nadie entre esos dos polos debería tocarlo, porque hay una buena manera de aprender cada matiz del modelo de objetos ADO.NET y los conjuntos de datos mecanografiados no lo son.

O tome LINQ. Seductoramente es fácil escribir código LINQ sin tener una buena comprensión de IEnumerable<T>. Pero no es tan fácil escribir código LINQ mantenible sin ese conocimiento.

Answer 7

Puedes pensar en .NET como una cebolla con muchas capas. Por ejemplo, .NET compact framework es un subconjunto de .NET completo. Además, hay capas "adicionales" en la parte superior de .NET en forma de "Extensiones" que son instalaciones opcionales para nuevas características que aún no se han convertido en parte de .NET propiamente dicha. Un ejemplo de esto sería cuando Microsoft lanzó ASP.NET 3.5 Extensions que ahora se ha incluido en .NET 3.51.

Otra forma de pensar en .NET es como un conjunto de "bibliotecas" que puede usar. Por ejemplo, hay un conjunto o rutinas para admitir RegEx. Si quiere o necesita expresiones regulares, entonces usa estas funciones, si no puede simplemente ignorarlas. Funciones simples para cosas como trigonometría o seguridad.

Así que supongo que realmente se reduce a lo que necesita para su aplicación? Si está haciendo una programación científica, es posible que desee las funciones trigonométricas. Una aplicación gráfica requerirá funciones que una aplicación de consola no haría. Las aplicaciones web probablemente no necesiten usar las funciones del portapapeles, etc.

Realmente no creo que haya API malas en .NET, solo programadores que las usan de forma inapropiada.

Answer 8

La interconexión remota generalmente es buena para evitar, al menos si tiene como objetivo 3.0 o superior y, por lo tanto, puede hospedar fácilmente puntos finales de mensajería en proceso.

Answer 9

Hay mucho que evitar en la biblioteca WinForms.

Evite el enlace de datos con la mayoría de los controles estándar de WinForms. Hay muchos errores en esa área que provocarán muchos rasguños en la cabeza. O al menos esa ha sido mi experiencia. NumericUpDown es un buen ejemplo de este desastre.

También evite los controles estándar de WinForms cuando se trata de grandes conjuntos de datos. Hacen una gran cantidad de copia de datos y no pueden tratar bien con grandes conjuntos de datos.

Evite ListView en modo "Virtual", ya que está lleno de errores.

En general, simplemente recomiendo mantenerse alejado de WinForms. Si tiene la opción, vaya a WPF o al menos compre una buena y bien respaldada (y afortunadamente menos problemática) biblioteca de formularios de terceros.