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.

Comments

• Anonymous
  April 20, 2009
  PingBack from http://www.anith.com/?p=30424

• Anonymous
  April 20, 2009
  Intresant post. Problemet är inte ramverket, problemet är användarna av det. Ca: 70% av frågor på .NET RIA Services forumet handlar om utvecklare som skapar stora modeller med EF, med relationer hit och dit, och de vill göra en kopia av sin domän modell och lägga den på klienten. De vill ha lazy loading mm. De skickar stora mängder data helt i onödan. Väldigt många utvecklare skapar ServiceOperationer i .NET RIA Services och tänker fortfarande i termer av API för lokala system. Så det är viktigt att utvecklare vet hur .NET RIA Services fungerar och vad tanken är med det och HUR man bygger RIA lösningar. Jag har pratar en del med Nikhil om detta och han är medveten om att många använder det på fel sätt, och det är en bra start ;)

• Anonymous
  April 23, 2009
  Du missuppfattar kritiken och jämförelsen med DCOM. DCOM tvingade inte heller in dig i något design-mönster och det stod dig fritt att köra chunky eller chatty calls precis om du själv ville. Problematiken var inte valfriheten runt de frågorna, problemet var att man förenklade det komplexa i att distribuera över flera skikt så till den grad att skikten blev "osynliga". DCOM var inte ensamt om det misstaget, samma misstag fanns i CORBA. Misstaget bygger på att utvecklare vill önska bort att skiktade lösningar är mer komplexa och svårare att bygga. Man vill att inte ta det extra arbetet som krävs för att bygga en lösning som är skiktad. Man är lat helt enkelt. Sanningen är att skiktet alltid kommer att finnas där och problematiken är inte att hitta ett abstraktionslager högt nog för att ta bort nätverkskommunikationen, det är lätt. Problemet är att nätverkskommunikation kräver en annan utvecklingsmodell än den som är in-process. Exakt det här visste man när man designade WCF, därför är det i WCF väldigt påtagligt när man lämnar ett skikt och går till ett annat, därför är man väldigt tydlig med kontrakts definitioner och meddelanden.  Man tyckte att det var så viktigt att visa på skillnaden att man i första versionen inte tillät återanvändning av data kontrakt i verktygen. Det är det här som är problemet med RIA-services, man försöker "hjälpa" utvecklare som inte vill se skiktet att bygga skiktade applikationer. Det är dem och inte de som förstår problematiken med skiktade lösningar som RIA services vänder sig till och de är de som inte behöver ett abstraktionslager utan en lektion i komplexiteten i skiktning. "Hmmm…. litar du då inte heller på den klientproxy-kod som Visual Studio skapar när du lägger till en webbservice-referens" Nej det är korrekt det gör jag inte, den proxy som genereras innehåller en mängd designfel och i de allra flesta fall abstraherar jag bort den eller bygger eget som bättre följer grundläggande principer som Interface Seggregation tex. "den kod som din favorit-OR-mapper genererar" Min favorit OR-Mapper genererar ingen kod utan använder den kod som jag ger den. F-Ö är det här att jämföra äpplen och päron. Vad gäller RIA försöker man dölja komplexiteten med skitkning, för ORM abstraherar man bort vanliga data access frågor som är samma som man själv skulle skriva. "backningsfält som du får när du använder den nya syntaxen för egenskaper i C# 3?" Igen, äpplen och päron. De här påverkar inte min arkitektur eller design av min lösning. "Sluta koda – börja jobba!”. Absolut, men man får inte förväxla "simple" med "simplictic". Erik Dörnenburg från Thought Works pratade om det på Developer Summit för ett par år sedan, finns en write-up här: http://www.lowendahl.net/showShout.aspx?id=136 Till sist, "First rule of distributed objects, don't distribute objects" - Martin Fowler

• Anonymous
  April 25, 2009
  @Löwendahl: "Du missuppfattar kritiken och jämförelsen med DCOM. DCOM tvingade inte heller in dig i något design-mönster..." Jag säger inte att DCOM tvingade in dig i något designmönster. Det var två olika invändningar mot .NET RIA Services som jag ville bemöta: ".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" Ledsen om jag formulerade mig en smula oklart. @Löwendahl: "Problematiken var inte valfriheten runt de frågorna, problemet var att man förenklade det komplexa i att distribuera över flera skikt så till den grad att skikten blev "osynliga"." Och här tycker jag att .NET RIA Services skiljer sig markant åt jämfört med DCOM. .NET RIA Services är i mina ögon mycket mer transparent och försöker inte på samma sätt gömma att det är ett distribuerat system som det handlar om. "First rule of distributed objects, don't distribute objects" Lite av poängen med min postning var att visa att .NET RIA Services i sig inte hindrar dig från att använda dina egna DTO:er eller datakontrakt anpassade för din klient-vy - samtidigt som du kan dra nytta av ramverkets andra fördelar (validering, paginering, säkerhet osv).

• Anonymous
  May 06, 2009
  /Kan/ och /kommer att/ är inte samma sak. Du kunde även med DCOM använda egna DTO:er, det var faktiskt ansett som best practices, men det var väldigt få i Microsoft communityn som följde dem för det ansågs "jobbigt med duplicerad kod". Om man bygger ett ramverk som skall följa Martin Fowler's första regel så gör man det lätt att använda DTOer och svårt att inte göra det, men RIA gör tvärtom. Det enklaste med RIA är att bara återanvända sin serverkod rakt av, vilket är det folk kommer att göra. "Och här tycker jag att .NET RIA Services skiljer sig markant åt jämfört med DCOM. .NET RIA Services är i mina ögon mycket mer transparent och försöker inte på samma sätt gömma att det är ett distribuerat system som det handlar om." Här skiljer våra åsikters sig åt, WCF är en typisk teknik där distributionen är tydlig. RIA är ett verktyg för att "hjälpa" utvecklare med det "komplicerade" i distribution och därför förenklar man och abstraherar, ur mitt perspektiv, fel saker. En viktig sak som jag tycker att Microsoft ibland glömmer med sina ramverk är att "enkelt" inte alltid behöver betyda optimalt eller ens rätt. Här är RIA och balanserar väldigt farligt, de hade tjänat på att ta in tex Don Box ett tag och lyssna på vad han har att säga om deras teknik innan de försätter utvecklare i ytterligare ett DCOM träsk. Tekniken är ju dock inte färdig utan mina observationer baseras på de designideér som RIA teamet pratar om för tillfället. De kanske ändrar sig till release, vem vet.

• Anonymous
  May 08, 2009
  Efter att blivit upprörd av att läsa på Silverlight.net forumet av .NET RIA Services, så har jag haft en diskutioner med Nikhil, och jag har även skrivet ett inlägg som Brad har kommenterat.. kanske kan vara av intresse? http://weblogs.asp.net/fredriknormen/archive/2009/04/30/will-net-ria-services-be-the-silver-bullet.aspx