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

Question

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

#1 da (5 voti)
#2 da (1 voti)
#3 da (1 voti)

9

Ci sono molti "sapori" del .NET Framework :

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

Quando il codice C # è necessario su una nuova piattaforma, sembrerebbe che Microsot preferisca prendere l'intero CLR e ridurlo a un piccolo sottoinsieme, creando nuovi assiemi e tipi mobili, invece di usare solo assiemi esistenti come quelli nel BCL. Silverlight ad esempio ha diverse classi / metodi per WPF (anche per alcuni metodi con firme leggermente diverse o implementazioni molto diverse), invece di fare semplicemente riferimento alla stessa implementazione di List<T> di WPF.

Questa è l'architettura ideale o un segno di eredità? Non dovrebbe funzionare il BCL su tutte le piattaforme, con solo diverse librerie di presentazione / IO su ciascuna? O il BCL e le altre librerie sono troppo gonfie e dividerle creerebbe troppi problemi di retrocompatibilità, per essere accettabile?

Se partivamo da una tela bianca e non eravamo preoccupati della compatibilità con le versioni precedenti, la situazione attuale sarebbe davvero il modo migliore per gestire più piattaforme?

frameworks .net silverlight

posta Paul Stovell 24.01.2012 - 20:39

fonte

3 risposte

Leggi altre domande sui tag frameworks .net silverlight

Chi ha creato o reso popolare l'XMLHTTPRequest / MSXML originale? Come gestisci le dimensioni del database in costante cambiamento?

score 5 · Answer 1

Ciò che Microsoft sta facendo, dividere 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 alcun senso includere in quella versione tutto il necessario per eseguire un'interfaccia grafica completa per esempio.

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

score 1 · Answer 2

Non penso che .NET sia il problema. Sebbene esistano vari runtime, sono comunque compatibili, motivo per cui tecnologie come Librerie di classi portatili funziona (per la maggior parte dei runtime che hai elencato).

For example, shouldn't each flavor reference a single, shared assembly called "System.Collections.dll", instead of each runtime having its own copy of System.dll/mscorlib.dll with various copies of the collections?

Perché è necessario? Fintanto che sono tutti compatibili (di nuovo, vedi le librerie di classi portatili), questo non dovrebbe avere importanza, poiché il BCL è parte del runtime stesso e distribuito in tandem.

score 1 · Answer 3

.NET sostituisce essenzialmente ed espande gli oggetti COM in un ambiente Windows. È anche usato per identificare molte tecnologie molto diverse, immagina se Adobe ha rinominato tutti i loro prodotti per avere una parola comune nel loro nome, è una specie di cosa sta succedendo con .NET.