S#arp Architecute - not to like.

Igår så hade SweNug GBG en dragning om S#harp Architecutre där Mikael från Dotnet Mentor gjorde en lysande presentation.

S#harp Architecture (sharp…) är ett paket med idéer från flera utvecklare hur de tycker du skall applicera Domän Driven tankegång (DDD- Domain Driven Design) ihop med exempelvis ASP.Net MVC och med hjälp av bland annat ORM (NHibernate) där de använder Fluent som grund.
Ramverket har templates för VS .Net m.m.

Rakverket i sig var ganska trevligt, dock mycket ful kod på sina ställen (mitt tycke). Det var många saker som var klumpigt implementerat men har säkert sin bakgrund. Ex Design By Contract delen gillade jag inte alls.

Ramverket i sig har massa designfel (inte kodmässigt). Exempelvis gillar jag inte idén att injektera Repositories klasserna in i MVC Kontrollerna. Repositories är typ data access klasserna, många känner nog igen likheten mellan dem med den fula notationen DAL eller Data.

Problemet med att skicka in dem blir att du helt plötsligt måste lägga in mer kod i don kontrollers än vad man egentligen bör göra. Du kan lätt få problem att skilja på businesslogik vs vanlig vypresentationslogik pga detta. Jag hade hellre sett att man injektade ett Applications lager /ApplicationService lager som i sin tur har logiken rörande repositories och domän serviceklasser. Detta för att lätt kunna ha olika UIs om det är ett krav för sin applikation. MVC skall vara löskopplat från sin applikation. MVC är designmönster för UI inget annat. På så sätt skall Kontroller (Controllers) mer eller mindre navigera systemet. Dvs innehålla Navigersingskod och info för presentera vyer. Men undantag finns ju självklart, som med allt i denna värld :/

En annan sak som jag inte blir klok på är alla Wannbe DDD som tror att entiteterna är Modellen. Hör upp =) en domän entitet är inte M:Et i MVC. Modelen i MVC är mer eller mindre en ViewModel. Den skall innehålla den info som krävs för att presentera och lagra data. Personligen hoppas jag det kommer finnas två modeller för en vy. En ViewModel och en EditModel. Där ViewModel har info som skall visas, EditModel info från vyn som man vill spara.

ASP.Net MVC har en hel del trevliga autobinding funktioner, dessa vill man gärna hantera smidigt. I ens Domän vill man helst ha DbC (Design by Contract) stöd. Problemet med att ha sin entitet (Databärare) är att använder du den som Model så kan du inte ha 100% stöd för DbC. Inte nog med det så får du även med mer info till Vyn än du behöver visa. M.m. (Tänk YAGNI) DbC har du för att ge snabb feedback till dig själv och andra att ”dude du använder min kod fel” detta för att öka kvalité och möjligheten att faktiskt inte kunna använda något på fel sätt. Många kan anse denna hantering onödig men det är mer tydligt när man faktiskt använde denna princip och upplever alla fördelar själv som man inser hur nyttigt det är för dig och dina kollegor.

Säg att du har en Address entitet den har ett value objekt Email. (Address.Email) när du sätter en E-mail adress och kör med DbC så skall du bla kolla så du inte sätter null värde och eller något annat än en giltig E-mail. Ett problem som uppstår när du ex använder din Address som model är att Autobindingen som då kommer få ett fel vid bindning om man ex lämnar en textbox tom. PS. Du kan ha klientvalidering om du vill för att ”kräva rätt värden till din Model” MEN tänk på att DbC är något alla klasser har och inget ett UI lager skall sköta åt dig. Vaklidering på UI-lagernivå finns där för att minimera fel och ge info om saker man måste fylla i. Sen så händer allt bakom skalet och det är där det viktiga händer och det är där det inte får gå fel. Det är bla detta DbC hjälper dig med.

Annotationstöd finns också som kräver att vissa saker uppfylls på sina Modeller. Som kan presentera en snygg Summary och vilka färlt som har krav på att vara ifyllda. Det går att använda dessa för ex DbC problemet är att dina Entiteter (om du envist skall använda dem som model) får en refference och beroende med UI. Domänlagret i DDD skall inte känna till vad som finns ovan. Ex Den skall inte han kännedom eller vara låst till ditt UI. Ett annat fel många gör när de nyttjar MVC och DDD.

Det finns en sjö argument varför och förklaringar på en hel del forum ang detta.

I övrigt så var S#harp Arcitecture en bra grund för att visa lite lätt hur man kan strukturera sin kod med NHibernate och ASP .Net MVC för de som inte är vana vid varken DDD eller MVC .