Innan jag ens börjar måste jag först dra några små "disclaimers".
- Det jag skriver nedan bryter mot minst en av grundpelarna i SOA (fler än så om man är lite petig). Det bör alltså användas med stor försiktighet och med en god anledning.
- Detta må se ut som ett mönster, men är det absolut inte av den enkla anledningen att det inte är beprövat. Vi har förvisso gjort liknande saker sedan länge, men inte i en ren SOA-miljö.
Sammanhang
Du bygger en ren entitetstjänst som ska leverera information till en eller flera konsumenter. Du ska även bygga en administrationsklient till denna information. Klienten behöver inte tillgång till någon annan informationskälla än det som tjänsten levererar och varje förändring i tjänstens interna datastruktur/logik kommer obönhörligt leda till att även klienten måste förändras.
Problem
ADO.NET inkluderar en hel del enkel och trevlig funktionalitet för att läsa och skriva till en databaskälla (DataAdapters, DataSet i kombination med DataGrid etc, etc). För många applikationer är dessa på tok för simpla, men i just enkla administrativa klienter kan de vara mycket kraftfulla. I en rent serviceorienterad arkitektur kan de dock inte användas på något vettigt sätt eftersom de "by design" är väldigt kopplade till databasens struktur.
Lösning
Se den administrativa klienten som ytterligare en "endpoint" till tjänsten. På så vis kan du tillåta att den har kännedom om den interna datastrukturen (på samma sätt som implementationen av dina .asmx-filer har).
Fördelar
- Du slipper det extrajobb som det kan innebära att bygga och underhålla en eller flera endpoints som den bara en administrativ klient använder
- Du kan använda dig av de inbyggda verktygen i Visual Studio 2005 för att enkelt koppla dig mot din databas
Nackdelar
- Du bryter mot SOAs grundpelare.
- Varje gång du sjösätter en ny version av din tjänst så måste även den administrativa klienten uppdateras.
Detta inlägg är ett "work in progress". Har du några kommentarer? Skriv!
Coding Insomnia 
Leave a Reply