Det stora slaget: ASP.NET AJAX mot AjaxPro
Eftersom Michael Schwarz har slutat utveckla AjaxPro.NET har vi gjort en utvärdering av andra alternativ för vår AJAX-/Utveckling. Våra bedömningsgrunder är:
- Integrerbarhet med .NET och våra /Utvecklingsmiljöer
- Snabbhet och effektivitet
- Storlek och antal filer att inkludera på varje sida
- Framtidssäkerhet
- Snygghet och allmän känsla
AJAX ASP.NET som är inbyggt i .NET 3.0.
I grund och botten kan man dela upp det inbyggda stödet i .NET i tre grupper:
a. UpdatePanels och AJAX-kontroller (uppdatera delar av sidan utan synlig omladdning)
<asp:UpdatePanel RenderMode="Inline" runat="server" UpdateMode="Conditional">
<ContentTemplate>
<asp:Label runat="server" ID="UpdateMe">Static text</asp:Label>
<asp:Button runat="server" ID="Button1" OnClick="Button1_Click" />
</ContentTemplate>
<Triggers >
<asp:AsyncPostBackTrigger ControlID="Button1" />
</Triggers>
</asp:UpdatePanel>
b. Statiska webmetoder (Webmethods direkt på sidan, nästan exakt samma implementation som AjaxPro)
Default.aspx.cs:
[WebMethod(true)]
public static string AJAXHello(string name)
{
return "Hello " + name;
}
c. Anropa en Web Service (.asmx) direkt från JavaScript
<a href="javascript:webservice.hello(prompt('Namn?'), function(result){alert(result)});">Call WebService</a>
Webservice.asmx:
[WebMethod]
[ScriptMethod(UseHttpGet = true)]
public DateTime Hello(string name)
{
return "Hello " + name;
}
Vi kan direkt konstatera att alternativ a (UpdatePanel) är förkastligt då den anropar och binder om hela sidan vid varje anrop, därefter görs en klientmatchning som uppdaterar de delar av sidan som har uppdaterats. Detta skapar väldigt stor overhead och fungerar endast på enkla sidor och sådana behöver man oftast inte implementera AJAX på överhuvudtaget.
Alternativ b kändes intressant men har begränsningen att man måste skriva det mesta av JavaScript-anropen själv – AjaxPro genererar ju automatiskt en proxyklass som hanterar alla anrop. Dessutom kan man inte göra denna typ av anrop på en UserControl.
Alternativ c är mest intressant då detta får fördelen att man skapar en standardiserat SOAP-gränssnitt som man integrera även på andra sätt än AJAX. Några nackdelar i jämförelse med AjaxPro är att man själv behöver konvertera de flesta mer komplicerade objekten till JavaScript själv. Att t.ex. överföra en DataTable eller ett DataSet direkt till klienten resulterar i serialiseringsproblem.
(Jämför man hastigheten med AjaxPro märker man också att eftersom alla anrop måste gå via XML tar konverteringen till JavaScript längre tid än JSON som AjaxPro använder sig av. Nu är står ju X:et i AJAX just för XML så man får nog stå ut med denna nackdel i hastighet med tanke på framtidssäkerheten i XML.)
Förutom ovanstående nackdelar kan man också notera att minimiantalet include-script är fyra dynamiskt genererade jämfört med ett statiskt i AjaxPro vilket skapar en overhead av 117 kb innan man lagt på sitt favorit-JavaScript UI-bibliotek (ExtJS eller YUI?).
Poäng AJAX ASP.NET:
- Integrerbarhet med .NET och våra /Utvecklingsmiljöer: 5 av 5
- Snabbhet och effektivitet: 1 av 5
- Storlek och antal filer att inkludera på varje sida: 2 av 5
- Framtidssäkerhet: 5 av 5
- Snygghet och allmän känsla: 2 av 5
AjaxPro jämförelsepoäng:
- Integrerbarhet med .NET och våra /Utvecklingsmiljöer: 5 av 5
- Snabbhet och effektivitet: 4 av 5
- Storlek och antal filer att inkludera på varje sida: 4 av 5
- Framtidssäkerhet: 2 av 5 (biblioteket är dock Open Source vilket ger en viss trygghet)
- Snygghet och allmän känsla: 5 av 5
Vår slutsats är därför: Trots att /Utvecklingen är nedlagd så är det i väntan på bättre alternativ bättre för oss att jobba vidare med AjaxPro och hoppas att det finns andra utvecklare som just nu jobbar på ett bättre och mer integrerat alternativ för .NET (förhoppningsvis en direkt ExtJs-implementation till .NET). Dessutom ska det bli spännande att se vad MVC.NET erbjuder i AJAX-väg plus att det ryktas om att det finns JSON-stöd i nya WCF (Windows Communication Framework) - mer om det längre fram.
Den högsta önskan är dock att vi snart slipper Javascript helt och kan gå över till C# även på klienten i och med SilverLight 2 som snart släpps i Beta.
// Christian & Tommy
Christian Landgren
2008-02-26