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.
Recent Comments