Query object pattern och Command pattern

Det vanligaste förekommande designmönstret när man bygger system är något slags fler-lagers-mönster, man har ett UI, ett servicelager och ett datalager. Datalagret är oftast implementerat på ett sätt som abstraherar bort själva accessen till datalagringen, kanske med hjälp en datacontext för koppling mot SQL Server eller annat (R)DBMS. Det är egentligen inget dåligt mönster, men jag känner att det skulle ändå vara skönt att platta ut strukturen lite och få färre lager att hantera. Kanske skulle man kunna tänka bort lagren helt? Tänk dig att kunna fokusera mer på vad man vill göra med data i sitt system istället för att lägga en massa energi på var, i vilket lager, olika operationer ska utföras.

Introduktion

Bara för att man INTE abstraherar i många lager behöver det INTE betyda att man förlorar testbarhet eller gör kopplingarna mellan dom olika delarna i systemet hårdare. Mönstren behöver INTE komma tillsammans, man kan välja det ena, det andra eller båda två.

Mönstren som det handlar om, som i detalj kommer att presenteras i två kommande poster, är:

  • Query object pattern
  • Command (object) pattern

Som namnen på mönstren antyder så innebär Query object pattern att man efterfrågar data medan Command pattern är en begäran om att utföra någon handling. Mönstren i kombination påminner en hel del om CQRS, Command-Query-Responsibility-Segregation. CQRS är stenhårt när det gäller att skilja på läsa data, query, och modifiering av data, command. Detta gäller även för Query object pattern, som bara ska läsa information och inte ha några andra sidoeffekter som modifierar data i systemets domän. Ett Command däremot kan man ha förväntningen på att det ska modifiera data.

Som ni säkert förstår, efter den hårda skillnaden mellan Query och Command, så ska implementationen av dom olika mönstren vara helt separerade. För den som använder sig av t.ex. Visual Studio så kommer koden i dom olika mönstren inte dela något projekt, möjligtvis med undantag för projekten för entiteters koppling mot ett datalager, men det är inte alls tvunget.

Vill man läsa mer om CQRS och domän-driven utveckling, läs här:

Nu är det dags att dra igång att koda, vi börjar med Query object pattern: