Perché abbiamo così tanti gusti di .NET? è una cosa buona? [chiuso]

Esistono molti "sapori" di .NET Framework :

Completo ("normale")
Sottoinsieme del profilo client
Silverlight nei browser web
"Silverlight" su Windows Phone
Quadro compatto
WinRT

Quando è necessario il codice C # su una nuova piattaforma, sembra che Microsot preferisca prendere il CLR completo e ridimensionarlo in un piccolo sottoinsieme, creando nuovi assiemi e spostando i tipi in giro, invece di utilizzare solo assiemi esistenti come quelli nel BCL . Silverlight ad esempio ha classi / metodi diversi a WPF (anche fino ad alcuni metodi con firme leggermente diverse o implementazioni molto diverse), invece di fare semplicemente riferimento alla stessa implementazione di List<T>WPF.

È questa l'architettura ideale o un segno di eredità? Il BCL non dovrebbe funzionare su tutte le piattaforme, con solo librerie di presentazione / IO diverse su ciascuna? Oppure il BCL e le altre biblioteche sono troppo gonfie e dividerle creerebbe troppi problemi di compatibilità con le versioni precedenti, per essere accettabili?

Se fossimo partiti da una tela bianca e non fossimo preoccupati per la retrocompatibilità, la situazione attuale sarebbe davvero il modo migliore per gestire più piattaforme?

.net frameworks silverlight

— Paul Stovell
fonte

Cosa c'è con tutti i voti stretti? Questa è una domanda perfettamente legittima.

— Mason Wheeler,

Sembra che potrebbe essere chiuso, probabilmente perché è un po 'giudicato (sembra che tu abbia già deciso che è "mal progettato"). Potresti voler riformularlo come " perché ci sono così tanti gusti di .NET?"

— FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner ha ragione. La domanda inizia con un pregiudizio nei confronti di .NET. Se il tono fosse più neutrale, sospetto che non sarebbero stati espressi voti ravvicinati.

— Oded,

Mi sembra che tu stia cercando di iniziare una discussione, non cercando risposte costruttive alla tua domanda. Immagino che sia per questo che stai ottenendo voti stretti.

— Tyanna,

@Oded e altri - Ho riformulato il titolo e il corpo, spero che si incontrino con la tua approvazione :)

— Paul Stovell,

Risposte:

Ciò che Microsoft sta facendo, suddividendo le routine in più pacchetti, è comune. Esiste una versione di .NET che funziona su computer a scheda singola (.Net Micro Framework) con memoria limitata. Non avrebbe senso includere in quella versione tutto ciò che è necessario, ad esempio, per eseguire un'interfaccia utente grafica completa.

Se guardi Apple, l'iPhone non contiene tutte le routine che si potrebbero trovare su un Mac.

— JonnyBoats
fonte

Ma piuttosto che uno sviluppatore che copia / incolla il codice per List<T>creare Micro Framework List<T>, il BCL non dovrebbe essere suddiviso correttamente in modo tale che i binari funzionino su tutte le piattaforme?

— Paul Stovell,

In altre parole, non dovrebbe far funzionare il codice su un'altra piattaforma solo per scegliere quali assembly supportare?

— Paul Stovell,

Anche Java lo fa. Ad esempio, Java Card è un sottoinsieme di Java.

— Bernard,

@PaulStovell: Non sono sicuro di come MS lo faccia ... ma non sarei sorpreso se MS avesse un percorso / script di compilazione separato (per dirla alla leggera) che prende il codice e lo costruisce per la piattaforma di destinazione - quindi non è una copia / incolla di List<T>ma potrebbe eliminare alcune cose dal codice o fondersi con alcune cose specifiche della piattaforma e produrre un elemento di distribuzione.

— Steven Evers,

Non penso che .NET sia il problema. Mentre ci sono vari runtime, sono ancora compatibili, motivo per cui funzionano tecnologie come le Portable Class Libraries (per la maggior parte dei runtime che hai elencato).

Ad esempio, ogni sapore non dovrebbe fare riferimento a un singolo assembly condiviso chiamato "System.Collections.dll", invece che ogni runtime abbia la propria copia di System.dll / mscorlib.dll con varie copie delle raccolte?

Perché è necessario? Finché sono tutti compatibili (di nuovo, consultare le Librerie di classi portatili), questo non dovrebbe avere importanza, poiché il BCL fa parte del runtime stesso e viene distribuito in tandem.

— Reed Copsey
fonte

Non dovrei essere in grado di scrivere una classe che la utilizza List<T>e la esegue solo su qualsiasi piattaforma senza creare una libreria portatile? O non dovrebbe List<T>essere in una libreria portatile? Le librerie portatili mi sembrano una soluzione alternativa piuttosto che parte di un design elegante.

— Paul Stovell,

.NET sta essenzialmente sostituendo ed espandendo oggetti com in un ambiente Windows. Viene anche usato per identificare molte tecnologie molto diverse, immagina se Adobe rinominasse tutti i suoi prodotti per avere una parola comune nel loro nome, è una specie di cosa succede con .NET

— Ryathal
fonte