Därför är .NET RIA Services inte DCOM i repris
Några saker som jag verkligen gillar med .NET RIA Services är hur hur väl det passar in i en modern flerskiktad arkitektur och hur få krav ramverket egentligen ställer på hur du exakt implementerar din lösning. Några invändning mot det nya ramverket som jag hörde under Developer Summit var:
- .NET RIA Services är DCOM i repris, det bryter mot vedertagna mönster att dela objekt mellan server och klient samt Jag vill inte tvingas in i att designa min lösning på ett speciellt sätt
.NET RIA Services är i mina ögon väldigt långt ifrån DCOM. Bl.a. eftersom ramverket helt bygger på att det är distribuerade applikationer det handlar om och inte gömmer distributionen på samma sätt som DCOM gjorde (med DCOM var kanske inte ens utvecklaren säker på om/när logiken skulle distribueras över flera skikt). DCOM var också notoriskt svårt att felsöka. Med .NET RIA Services implementeras kommunikationen med hjälp av ADO.NET DataServices och JSON vilket är oerhört mycket mer transparent – starta upp Fiddler och du får direkt en vy i klartext över hur din klientapplikation kommunicerar med ditt tjänstelager.
Ramverket tvingar inte heller in dig i speciellt många designval utan det står dig helt fritt att anpassa din lösning så att den passar dina krav. Använd deklarativa bindingar, filtreringar och valideringar på klientsidan ifall du vill eller strunta i det och skriv allt för hand själv. Vill du göra flera mindre CRUD-anrop mot din tjänst eller vill du samla ihop dina anrop mot servern i mer “chunky” anrop - som utför en “unit of work”, det är helt upp till dig. Vill du låta ramverket serialisera dina objekt direkt eller vill du använda någon form av Data Transfer Objects – du bestämmer själv.
Fredrik Normén har skrivit en intressant artikel där han beskriver hur han använder en slimmad modell som är anpassad för presentationslagret i en .NET RIA Services-lösning – istället för att skicka domänobjekten direkt fram och tillbaka från klienten.
Vill du använda någon annan databas än SQL Server, använda t.ex. StructureMap för OR-mappning och använda en annan typ av autentisering än den inbyggda Autentication Domain Service? No problemas – här finns en artikel som beskriver hur du går tillväga.
En annan invändning som jag hört mot ramverket är: Jag litar inte på automatgenererad kod.
Hmmm…. litar du då inte heller på den klientproxy-kod som Visual Studio skapar när du lägger till en webbservice-referens, den kod som din favorit-OR-mapper genererar eller de backningsfält som du får när du använder den nya syntaxen för egenskaper i C# 3? Personligen så håller jag med Per Tronelius, en före detta kollega, som en gång avslutade ett seminarie om kodgenerering med uppmaningen “Sluta koda – börja jobba!”.
Just möjligheten att automatiskt hålla valideringskod i synk mellan server- och klientssideskod är ju annars något som jag personligen tycker är en av de absolut största fördelarna med .NET RIA Services. Dessutom så kan du anpassa och förändra hur kodgenereringen sker.
En sak som jag själv däremot har tyckt saknats är ett bra exempel på hur man kombinerar .NET RIA Services med MVVM-mönstret för en snyggare separering av ansvar i klientdelen av sin applikation. Men – jag såg precis att Nikhil Khotari (som är en av de huvudansvariga arkitekterna för .NET RIA Services) har publicerat ett sånt exempel på sin blogg.