|
|
Publicerad på 2016-07-07 10:15:06
|
|
|
dynamisk är en ny funktion i FrameWork 4.0. Framväxten av dynamisk har gett C# egenskaper hos en svag språktyp. Kompilatorn kontrollerar inte längre typen vid kompilering, och det dynamiska objektet stöder som standard vilken funktion du vill under kompileringstiden. Till exempel, även om du inte vet något om objektet som returneras av GetDynamicObject-metoden, kan du göra ett kodanrop på det här sättet, och kompilatorn rapporterar inget fel:
När det gäller korrekt användning bör en felaktig användning påpekas först:
Folk använder ofta nyckelords-var för att jämföra med dynamisk. Faktum är att var och dynamisk är helt två begrepp och inte alls bör jämföras tillsammans. När den är kompilerad matchar kompileringstiden automatiskt den faktiska typen av variabeln och ersätter variabelns deklaration med den faktiska typen, vilket ser ut som om vi deklarerar den faktiska typen vid kodning. Efter att dynamisk har kompilerats är det faktiskt en objekttyp, men kompilatorn gör särskild behandling av den dynamiska typen, så att den inte utför någon typkontroll under kompileringen, utan lägger typkontrollen i körtiden.
Detta kan ses i redigeringsfönstret i Visual Studio. Variabler deklarerade som vars stödjer "intelligent sense" eftersom Visual Studio kan härleda den faktiska typen av var-typer, medan variabler deklarerade som dynamiska inte stöder "intelligent sense" eftersom kompilatorn inte vet något om typen av sin runtime. Att använda Intelligent Sense för dynamiska variabler visar "Denna åtgärd kommer att lösas vid körning".
Det faktum att den dynamiska variabeln är en objektvariabel kan verifieras av IL-koden, och IL-koden kommer inte att publiceras här. Självklart hanterar kompilatorn också dynamiska deklarationer för att skilja mellan direkta objektvariabler.
dynamiskt renderas i stor utsträckning i MSDN för att förenkla interoperabilitet, och jag känner att det är på grund av detta som vissa utvecklare missförstås: eftersom många utvecklare inte vet hur man använder kodning som COM+ och OFFICE sekundär utveckling, behöver de akut en dynamisk applikationsanledning. Så, i daglig utveckling tycker jag att dynamik är värdefullt:
Typkonvertering
Att växla mellan dynamiska instanser och andra typer av instanser är enkelt, och utvecklare kan enkelt växla mellan dynamiska och icke-dynamiska beteenden. Varje instans kan implicit konverteras till en dynamisk typinstans, se följande exempel:
dynamisk d1 = 7;
dynamisk d2 = "en sträng";
dynamisk d3 = System.DateTime.Today;
dynamisk d4 = System.Diagnostik.Process.GetProcesses();
Omvänt kan en implicit konvertering dynamiskt tillämpas på vilket uttryck av typ dynamiskt som helst.
Och vice versa kan varje uttryck av typ dynamisk också implicit konverteras till andra typer.
int i = d1;
sträng str = d2;
DateTime dt = d3;
System.Diagnostics.Process[] procs = d4;
Överbelastningsproblem med dynamiska typparametrar i metoden
Om en metod anropas passerar ett objekt av typen dynamisk, eller om objektet som anropas är av typen dynamiskt, sker bedömningen av överbelastning vid körning och inte vid kompileringstid.
Dynamiskt språk runtime DLR
Den dynamiska språkkörningen är . NET Framework 4 Beta 1 är en ny uppsättning API:er som erbjuder stöd för dynamiska typer i C# och även implementerar dynamiska programmeringsspråk som IronPython och IronRuby.
Dynamik förenklar reflektioner.
Tidigare använde vi reflektioner som denna:
Nu har vi ett förenklat sätt att skriva:
Vi kan vara avfärdande mot en sådan förenkling, det verkar ju som att koden inte har minskats mycket, men om vi tar hänsyn till de två egenskaperna effektivitet och skönhet är fördelarna med dynamisk uppenbarelse. Kompilatorn optimerar dynamisk för att vara mycket snabbare än ocachad reflektionseffektivitet. Om du måste jämföra kan du köra koden för de två ovanstående (anropet Add-metoden) för 10000000 för att dra en slutsats.
|
Föregående:mvc hämtar JSON XML-data för inläggetNästa:Ett igenkänningsfel uppstod. nära linje 1, kolumn 10
|
