Seit heute gibt es auf der Connect-Site von Microsoft die CTP-Version von VS 2010 und .NET 4.0 download. Ich denke, ich werde bestimmt auch bald die Installation auf mich nehmen.
Ich habe mich heute an das Upgrade meiner ASP.NET MVC Applikation auf die Beta-Version gestürzt. Mit dem Beta-Status ist die MVC-API als relativ stabil zu bezeichnen, so dass mit der nächsten und ggf. übernächsten Version kaum Änderungen zu erwarten sind.
Den Anfang der heutigen Aktion machte der Download des Beta-Releases und anschließend der Download des Future-Assembly. (Im Zweifel beides immer über Codeplex ASP.NET zu erreichen)
Der nächste Schritt war das lesen des Blog-Posts von ScottGu, so dass man wieder auf dem Laufendem ist. Allerdings sind soviele neue Features drin, die ich nicht wirklich nutzen kann/will. Einiges ist sehr cool, aber deutlich zu spät für mich.
Als erstes mussten alle Namespaces in der Config angepasst werden. Es kommen 2 neue Namespaces hinzu:
Anschließend musste die Html.Form<>-Helper aufrufe umgeschrieben werden, allerdings zum Glück nur durch die Methode Html.BeginForm<> zu ersetzen. Doch Achtung, die Generic-Versionen sind nur im Future-Assembly zu finden. Ist dieses nicht referenziert, so wird die Methode nicht gefunden.
Der 3. Knackpunkt, der mich kurz aus der Bahn geworfen hat, war eine Änderung am OutputCaching. Dieses muss genau die gleiche Angaben enthalten, wie es bei der Page-Direktive notwendig ist. ([OutputCache(Duration=20, VaryByParam=*)] oder [OutputCache(Duration=20, VaryByParam=none)])
Anschließend war "alles" schick und es lief wieder. Zumindest sind mir derzeit keinerlei weitere Probleme entgegen gekommen.
Für das Layout von WCF-Projektstrukturen gibt es relative klare Empfehlungen, leider sind die in den Visual Studio Templates nicht abgebildet. Im Gegenteil, es wird von vielen Architekten und Entwicklern im WCF-Umfeld empfohlen, komplett auf diese Templates zu unterstützen. Es wird einfach zu viel gemacht, dass gar nicht notwendig ist und das eine saubere Trennung erschwert. Die Empfehlung für WCF-Projekte sieht vor, dass Contracts, egal ob Data- oder ServiceContract[s] in einem separaten Assembly (Class-Library) abgelegt werden. Die Implementierung der Services und weiterer Schichten kann dann, wie bei WebService oder anderen Projekten durchgeführt werden.
Assemblies:
Oft wird auch oft empfohlen, dass man eine Fassaden-Architektur einzieht, wobei dass sehr umstritten ist. In der Fassade wird die spezielle Behandlung von FaultContract(s) durchgeführt, Artikel zu WCF-Exception Handling "Exception Handling in WCF using Fault Contract". Außerdem kann man die Fassade sehr gut dazu benutzen, Exception-Informationen von der Außenwelt zu verbergen.
Sind die Contracts sauber in dem separatem Assembly programmiert, kann dieses Assembly in .NET-Clients verwendet werden. Dadurch spart man sich die "hässliche" Generierung von Services auf dem Client. In allen Projekten, die ich durchgeführt habe, hat sich das als der beste Weg herausgestellt. Allerdings ist darauf zu achten, dass nur ein Vertrag in dem Assembly eingeführt wird. Die Implementierung von Logik hat in den Verträgen nichts zu suchen und würde die Unabhängigkeit von Client und Service verhindern. Ist das der Fall, hat man eine bessere .NET Remoting Lösung erstellt. Nur noch einmal zur Klarstellung, dass Contract-Assembly muss nicht genutzt werden, aber es ist sauberer für .NET Clients.
Ich bin etwas spät, aber bevor ich es niemals mehr blogge kommt heute der Artikel zu JS. Ich habe mir endlich mal wieder Zeit für das Bloggen genommen und bin auch froh. Meine Arbeitslage hat sich sehr plötzlich etwas entspannt.
Der ScriptManager aus dem .NET Framework 3.5 kann JavaScripte auf dem Server zusammenfassen. Das bedeutet, dass eine Anzahl von Scripten in ein größeres Script zusammengefasst wird. Es gibt mehrere Vorteile, die durch das zusammenfassen entstehen:
- weniger Server-Roundtrips für den Download der Script
- optimierte Script-Files (entfernte Kommentare, entfernte Zeilenumbrüche)
Das schwierige für das Zusammenfassen von Scripten ist allerdings herauszubekommen, was alles geladen werden muss. Hierfür existiert allerdings auch ein passendes Tools, mittels dem der Konfigurationsblock sehr einfach erzeugt werden kann. Der ScriptReferenceProfiler ist ein Server-Control, dass einfach auf der Webseite eingebunden wird. Beim Aufruf der Webseite erhählt man einen Script-Block als Ausgabe. Der Script-Block wird 1:1 in die ASP.NET-Seite eingefügt und zwar beim eingebundenen Script-Manager. Eine sehr gute Anleitung kann unter video-296.aspx angeschaut werden.
Ursprünglich eingebundener ScriptManager:
<asp:ScriptManager ID="ScriptManager1" runat="server"> </asp:ScriptManager>
Eingefügte Scripte, die zusammengefasst werden:
<asp:ScriptManager ID="ScriptManager1" runat="server"> <CompositeScript> <Scripts> <asp:ScriptReference Name="MicrosoftAjax.js" /> <asp:ScriptReference Name="MicrosoftAjaxWebForms.js" /> <asp:ScriptReference Name="”AjaxControlToolkit.Common.Common.js”" Assembly="”AjaxControlToolkit," Version="3.0.20229.17016," Culture="neutral," PublicKeyToken="28f01b0e84b6d53e”" /> <asp:ScriptReference Name="”AjaxControlToolkit.ExtenderBase.BaseScripts.js”" Assembly="”AjaxControlToolkit," Version="3.0.20229.17016," Culture="neutral," PublicKeyToken="28f01b0e84b6d53e”" /> </Scripts> </CompositeScript> </asp:ScriptManager>
Eigentlich ist das alles super einfach, allerdings kann es passieren, dass durch sehr viele Scripte die URL zu lang wird. Als Fehler kommt die Meldung "The resource URL cannot be longer than 1024 characters. If using a CompositeScriptReference, reduce the number of ScriptReferences it contains, or combine them into a single static file and set the Path property to the location of it." Das ganze hört sich wesentlich dramatischer an, als es ist. Um das Problem zu lösen, muss man die Scripte aufteilen. Dazu werden ScriptManagerProxy-Controls verwendet. Die Proxy-Instanzen sind ursprünglich für die Verwendung auf Unterseiten gedacht, um weitere Scripte oder Services einzufügen.
<asp:ScriptManager ID="ScriptManager1" runat="server"> <CompositeScript> <Scripts> <asp:ScriptReference Name="MicrosoftAjax.js" /> <asp:ScriptReference Name="MicrosoftAjaxWebForms.js" /> </Scripts> </CompositeScript> </asp:ScriptManager> <asp:ScriptManagerProxy ID="proxy1" runat="server"> <CompositeScript> <Scripts> <asp:ScriptReference Name="”AjaxControlToolkit.Common.Common.js”" Assembly="”AjaxControlToolkit," Version="3.0.20229.17016," Culture="neutral," PublicKeyToken="28f01b0e84b6d53e”" /> <asp:ScriptReference Name="”AjaxControlToolkit.ExtenderBase.BaseScripts.js”" Assembly="”AjaxControlToolkit," Version="3.0.20229.17016," Culture="neutral," PublicKeyToken="28f01b0e84b6d53e”" /> </Scripts> </CompositeScript> </asp:ScriptManagerProxy>
Ein sehr guter Artikel zu dem Thema wurde von Samir Bellouti geschrieben.
