¿Por qué tenemos tantos sabores de .NET? ¿Es una cosa buena? [cerrado]

9

Hay muchos "sabores" de .NET Framework :

  • Completo ("normal")
  • Subconjunto de perfil de cliente
  • Silverlight en navegadores web
  • "Silverlight" en Windows Phone
  • Marco compacto
  • WinRT

Cuando se necesita el código C # en una nueva plataforma, parece que Microsot prefiere tomar el CLR completo y desglosarlo en un pequeño subconjunto, creando nuevos ensamblajes y moviendo tipos, en lugar de simplemente usar ensamblajes existentes como los del BCL . Silverlight, por ejemplo, tiene diferentes clases / métodos para WPF (incluso hasta algunos métodos que tienen firmas ligeramente diferentes o implementaciones muy diferentes), en lugar de simplemente hacer referencia a la misma implementación de List<T>WPF.

¿Es esta la arquitectura ideal, o un signo de legado? ¿No debería ejecutarse el BCL en todas las plataformas, con diferentes bibliotecas de presentación / IO en cada una? ¿O el BCL y otras bibliotecas están demasiado hinchadas y dividirlas crearía demasiados problemas de compatibilidad con versiones anteriores para ser aceptables?

Si comenzamos desde un lienzo en blanco y no nos preocupamos por la compatibilidad con versiones anteriores, ¿la situación actual sería realmente la mejor manera de manejar múltiples plataformas?

.net frameworks silverlight Paul Stovell
fuente
77
¿Qué pasa con todos los votos cerrados? Esta es una pregunta perfectamente legítima.
Mason Wheeler
2
Parece que podría cerrarse, probablemente porque está redactado un poco juiciosamente (parece que ya has decidido que está "mal diseñado"). Es posible que desee reformularlo como " ¿por qué hay tantos sabores de .NET?"
FrustratedWithFormsDesigner
1
@FrustratedWithFormsDesigner tiene razón. La pregunta comienza con un sesgo contra .NET. Si el tono fuera más neutral, sospecho que no se habrían emitido votos cerrados.
Oded
2
Me parece que está tratando de comenzar una discusión, no buscando respuestas constructivas a su pregunta. Supongo que es por eso que está obteniendo votos cercanos.
Tyanna
2
@Oded y otros - Reescribí el título y el cuerpo, espero que se encuentre con su aprobación :)
Paul Stovell

Respuestas:

5

Lo que está haciendo Microsoft, dividir las rutinas en múltiples paquetes, es común. Hay una versión de .NET que se ejecuta en computadoras de placa única (.Net Micro Framework) con memoria limitada. No tendría ningún sentido incluir en esa versión todo lo necesario para ejecutar una interfaz gráfica de usuario completa, por ejemplo.

Si nos fijamos en Apple, el iPhone no contiene todas las rutinas que uno encontraría en una Mac.

JonnyBoats
fuente
Pero en lugar de que un desarrollador copie / pegue el código para List<T>crear Micro Framework List<T>, ¿no debería dividirse el BCL correctamente de modo que los archivos binarios se ejecuten en todas las plataformas?
Paul Stovell
2
En otras palabras, ¿no debería hacer que el código se ejecute en otra plataforma solo sea un caso de elegir qué ensamblajes admitir?
Paul Stovell
1
Java hace esto también. Por ejemplo, Java Card es un subconjunto de Java.
Bernard
2
@PaulStovell: No estoy seguro de cómo lo hace MS ... pero no me sorprendería si MS tuviera una ruta de compilación / script por separado (para decirlo a la ligera) que toma el código y lo construye para la plataforma de destino, así que no se trata de copiar / pegar, List<T>pero puede eliminar algunas cosas del código o fusionarse con algunas cosas específicas de la plataforma y producir un elemento de implementación.
Steven Evers
1

No creo que .NET sea el problema. Si bien hay varios tiempos de ejecución, siguen siendo compatibles, por eso funcionan tecnologías como las Bibliotecas de clases portátiles (para la mayoría de los tiempos de ejecución que enumeró).

Por ejemplo, ¿no debería cada sabor hacer referencia a un único ensamblado compartido llamado "System.Collections.dll", en lugar de que cada tiempo de ejecución tenga su propia copia de System.dll / mscorlib.dll con varias copias de las colecciones?

¿Por qué se necesita esto? Siempre y cuando todos sean compatibles (de nuevo, vea las Bibliotecas de clases portátiles), esto no debería importar, ya que el BCL es parte del tiempo de ejecución y se distribuye en tándem.

Reed Copsey
fuente
¿No debería poder escribir una clase que solo la use List<T>y ejecutar en cualquier plataforma sin crear una biblioteca portátil? ¿O no debería List<T>estar en una biblioteca portátil? Las bibliotecas portátiles me parecen una solución alternativa en lugar de parte de un diseño elegante.
Paul Stovell
1

.NET esencialmente reemplaza y expande objetos com en un entorno Windows. También se usa para identificar muchas tecnologías muy diferentes, imagínese si Adobe cambia el nombre de todos sus productos para tener una palabra común en su nombre, eso es algo que está sucediendo con .NET

Ryathal
fuente