Många av oss försöker att harmonisera O/R Mappers och SOA genom att säga att man kan använda en mapper för att skriva innehållet i en tjänst. Mappern blir en hjälp att hantera domänobjekt (typ Person, Order) på ett smidigt sätt. Vilket ofta innebär att man själv inte behöver tänka på mappningen mellan objekt och tabell/relationer i databasen, alltså att lagra informationen. En mycket stor fördel med O/R Mappers är att man kan bygga avancerade relationer mellan objekt, alltså att man via Personobjektet enkelt kan nå alla Orderobjekt som personen har.
Nu kommer jag till min fundering: O/R Mappers är ofta overkill att använda när man skriver SOA-lösningar.
Varför?
O/R Mappers fungerar bra när man har en domänmodell som man äger, alltså finns i samma applikation. Om vi tar exemplet med Person och Order, så måste O/R Mappern äga båda dessa objekt, alltså ha fullständig tillgång till dem. Detta bland annat av skälet att kunna skapa objektrelationer mellan dem.
Men enligt SOA skulle vi troligtvis inte bygga en tjänst som både innehåller Person och Order. Vi skulle istället ha en Persontjänst och en Ordertjänst. (Kom ihåg att SOA handlar om att skapa en struktur som är flexibel och förändringsvänlig, i en heterogen miljö.) Det gör att det inte är lika naturligt att använda en O/R Mapper för att skapa Persontjänsten. Ibland kan det fortfarande vara bra att använda en sådan, men inte alltid.
Med detta vill jag inte säga att Domain Driven Design (DDD) är något dåligt. Jag tror snarare att den tekniken är mycket användbar, speciellt för att designa de viktiga affärsobjekten i en verksamhet. Men det viktiga är att vi frigör objekten ifrån det hårt knutna situationen som blir när man använder sig av O/R Mappers. O/R Mappers skapar kopplingar mellan objekten på en för låg nivå. Detta är precis det problemet som vi idag har med objektorienterad programmering.
Hej,
Är inte med helt på vad du menar här.
O/R Maper är en hanterare för att data persistence mellan objekt och Datakälla.
Detta för att fylla upp objektens state.
Om du fyller upp objekt manuellt eller via Dataset spelar ingen roll, då bör samma problem uppstå.
En O/R Mapper måste inte känna till andra objekt. Det är det sköna med den. Dock behöver objektens mappningsfil ex XML-fil känna til vilket format O/R Mappern nyttjar och tolkar. Men detta är nått mellan datalagret och affärslagret och har inget med det publika SO interfacet att göra.
O/R mappers är helt löskopplat fårn Domän modelen vilket är ett stort mål i OO och om man lyfter en nivå även SOAs mål mellan tjänster.
Du säger även
"Men enligt SOA skulle vi troligtvis inte bygga en tjänst som både innehåller Person och Order. Vi skulle istället ha en Persontjänst och en Ordertjänst."
Även här finns det inget hinder att ha en Domän modell för detta. Person och Order kan mycket väl vara löskopplade. De kan även om man vill känna till varandra men det är då ett designval.
O/R mapper är i enkel for en ersättare för ex en SqlHelper där du själv får mappa dina attribut mot readers fält eller Datsets columner.
Mvh Johan
Posted by: Johan Normén | 2005-04-15 at 11.15
Problemet är väl snarare att det finns för många applikationer som innehåller just både data och logik för Person och Order. Att man har två tjänster, PersonService och OrderService, exponerade ifrån de applikationenerna är ingen SOA-purist behjälpt av. Applikationerna borde istället utgå från 2 tjänster och därefter skapa två av varandra oberoende implementationer och därmed få den lös kopplade arkitektur som SOA förespråkar.
Om den tjänsten sedan är bäst lämpad att implementeras mha en O/R-mapper eller Dataset kan vara osagt. Själv tycker jag man vinner mycket på en O/R-mapper eftersom man kan jobba metodiskt med TDD och refactoring. En ORM är mycket lättrörlig.
Däremot att utgå från en domänmodell för hela kravbilden, skapa en fullständig domänmodell, objektmodell och deploya den som en helhet i en app-server som sedan exponerar ett antal tjänster, kan ju aldrig kombineras med SOA.
SOA är ju, per definition, den motsatta utgångspunkten för design, dvs outside in, process centric och allt vad det heter. Helt ortogonalt synsätt.
Posted by: Jonas Ekström | 2005-04-16 at 11.04
Jonas verkar tycka ungefär som jag. Det som jag dock vill kommentera är att TDD och Refactoring är ingenting som O/R Mappers har någon ensamrätt på. Det går lika bra att använda sig av de teknikerna om man implementerar tjänsterna på andra sätt än via O/R Mapper.
O/R Mapper fördelen av att de snabbt kan bygga den interna domänmodellen i en tjänst. Och den kan fortfarande vara rätt avancerad, även om man bygger enligt SOA. Om det är så, kan jag mycket väl tänka mig att använda en O/R Mapper som jag litar på.
Posted by: Dag | 2005-04-16 at 11.11
Halloj!
En mycket intressant blogpost! Och kanske något att diskutera vidare på fredag?
En sak slog mig när jag läste och det är att jag tror många så att säga "börjar" i OR Mapper-änden, medan jag ser OR Mapper-grejen bara som en implementationsdetalj. Vad jag också försöker säga är att det bör vara ett designbeslut om person och Order skall vara tightly coupled eller inte... OK, nu upprepade jag nog bara vad som redan sagts.
:-)
Här är förresten en kul blogpost som kanske diskuterar problemet med enkelriktning, dvs att bara göra på ett sätt, snarare än att växla mellan olika...
http://udidahan.weblogs.us/archives/027329.html
Mvh
jimmy
www.jnsk.se/weblog/
###
Posted by: Jimmy Nilsson | 2005-04-17 at 15.52