Eftersom jag har varit ifrån affärsapplikationer och mer i fysiksimulering under en ganska lång tid har jag haft ett ganska ljumt intresse och känner jag att jag har halkat efter lite i diskussionerna där.

Vad är det som "är inne" idag? Vad ska jag läsa på om?

Låt säga att vi har en vb.net-applikation och en Accessdatabas.
Sen har vi tre scenarion:
1. Databasen är tre tabeller med superenkla 1->N-kopplingar. (Säg Företag, Anställda, Produkter)
2. Databasen är lite mer komplicerad med N->N-kopplingar, med en hel del "business logic".
3. Databasen är ytterligare komplicerad med självreferenser, primary keys över flera kolumner, hierarkisk data etc.

I det här fallet är O/R-mapper inte aktuellt, däremot allt "inbyggt" i .NET. Har kikat lite på http://msdn.microsoft.com/en-us/library/aa581769.aspx, är det rätt ställe att börja på, och rätt princip?

Accessdatabas, är inte det ute sedan 1996 ;)

Val av arkitektur beror på massor av aspekter, och det finns ingen Silver bullet..

1) Om det är väldigt få användare och en ren databas driven app, och bara 1-2 ASP.Net sidor, så kan du göra det enkelt för dig och köra med AccessDataSource kontrollern i .Net och köra med Code-less databinding. Ett annat alternativ är LINQ to SQL och använda dig av LinqDataSource control istället för SQLDataSource control, men då kan du inte köra med en Accessdatabas, då måste du ladda ner en 3de-parts lösning.

2) Regel nummer 1 - Ingen "business logic" i databasen.. Du nämner aldrig antal användare och storlek på projektet, så utifrån det är det svårt att säga extakt vilken arkitektur och lösning du skulle kunna använda dig av. Men är det ett väldigt litet projekt med få användare och väldigt få ASP.Net sidor, så kan laternativ 1) funka bra här. Annars skulle jag be dig ta en titt på Domain Driven Design (DDD).

3) Vad skiljer sig denna från 2)an!? ;) Ta en titt på Domain Driven Design..

"I det här fallet är O/R-mapper inte aktuellt", varför inte!? Passa perfekt... ta en titt på LINQ to SQL (Kommer ev försvinna i farmtiden) eller ADO.Net Entity Framework.

Rätt ställe tycker jag är att ta en titt på flera "design" och akritekturer, för om du ska ha rollen som arkitekt eller system design så är det viktigt att du vet om flera olika sätt att bygga en app. Ett tips är att läsa Eric Evans bok om Domain Driven Design, även Martin Fowlers bok "Patterns of Enterprise Application Architecture".

BÖRJA ALDRIG att designa och skapa databasen först och sedan dirva din design utifrån databasen, det är som att skjuta sig själv i foten..

För det första, notera att jag inte pratar om ASP.NET utan om windowsapplikationer (jag vet att artikeln handlar om asp.net, det är principerna jag är ute efter).

Sen vad gäller accessdatabas; vi snackar om små applikationer där vi inte vill behöva gå via it-support för att få en server till en databas; små lokala system med installationer på mindre än en halvtimme.
Alternativet är väl sqlite etc., men det är ju skit samma i sammanhanget.

Men andemeningen gick ändå fram.
1) Det första, enklaste alternativet är alltså att använda databinding med de autogenererade dataset-historierna. Vilken datasource man väljer är ju mer en fråga om hur själva kommunikationen mellan bindingen och databasen ska gå till, poängen är att man bara binder kontrollerna och så funkar skiten.

2) Så det är "ok" att använda databindings även då, men man får helt enkelt göra lite joins i frågorna?

3) Skillnaden är att man t.ex. skulle kunna vilja ha treeviewkontroller, att vissa inserts blir jävligt komplicerade osv. Funkar datasets bra ändå?

O/R-mapper är inte aktuellt eftersom det innebär att många på kort tid måste lära sig en specifik. Det blir en mer långsiktig plan.

<b>>Rätt ställe tycker jag är att ta en titt på flera "design" och akritekturer, för om du ska ha rollen som arkitekt eller system design så är det viktigt att du vet om flera olika sätt att bygga en app. [...]
BÖRJA ALDRIG att designa och skapa databasen först och sedan dirva din design utifrån databasen, det är som att skjuta sig själv i foten..</b>
Jag kanske framstod som lite mer amatörmässig vad gäller systemdesign än jag egentligen är, detta känner jag förstås till.

Jag känner också till begreppet DDD och några grova drag i metodologin, men vad jag är ute efter är egentligen är kort beskrivning av hur resp. scenario ovan skulle se ut i DDD. Ta det enklaste (även om det förmodligen är overkill i det fallet). Hur relaterar detta till principer som MVC, 3-tier osv.; det känns som att väldigt många begrepp överlappar varandra.


Hur lägger man upp scenario 1 med DDD, t.ex.?
Jag söker en slags crash course i hur ddd funkar. Jag tycker mig bara se små fragment som diskuterar detaljer när jag kollar i bloggar, och man borde kunna sammanfatta grundtankarna i något kortare än en bok.

MS Access fungerar inte 100% med 64-bitars versioner (som kommer mer och mer) så om du vill köra MS välj istället Sql Server CE som inte behöver någon instans igång för att ansluta till.


Du skriver att tanken är att ni skall använda DataSet's/DataTable's, det är en bra bit ifrån hur man vill göra i DDD.

DDD är en metodik hur du designar dina objekt vilka du ofta inte har när du kör med DataSet/DataTable's för där motsvarar en DataRow dit objekt om man tittar på det grovt.
Och skall du köra DDD så är nog en O/R Mapper att föredra.

Men som du skriver så kan ni inte tekniken just nu och detta är ett litet snabbt uppdrag, då kanske det är rätt som du säger att köra på det ni redan kan. Men frågan var vad som var rätt just nu? Isåfall hade jag svarat O/R Mapper och DDD :) och jag förespråkar NHibernate som O/R Mapper.

Boken av Eric Evans som Fredrik föreslog är en riktigt bra bok inom ämnet.

Det är svårt att säga "så här skulle jag gjort" när jag inte vet vem användarna är, hur systemet ska fungera etc. Men om du ska bygga en Windows App och kör på alt 1. där du har enbart 3 enkla tabeller.. och kanske max 2-3 Win Forms.. och inte så mycket affärslogik, då skulle jag valt att databinda kontroller med hjälp datasource mot databasen. Om du skulle köra med DDD så skulle du först berhöva ta fram en domän modell tillsammans med en domän expert.. Men om vi utgår från att det är en simple app där modellen kommer att bestå av Företag, Anställda och Produkter.. då skulle det ev kunna se ut som följande:

3 Entiter "klasser", Company, Employee och Product.. dessa tre har egenskaper som beskriver enitieten.

Sedan 3 st Repositories som hanterar sina entiteter.. tex:

CompanyRepository, EmployeeRepository och ProductRepository.. Se dessa som en "behållare", du hämtar dina entiteter från dom och updaterar och stoppar in nya etc... Det är Repositories som använder sig av OR-mappers, går även med vanlig ADO.Net etc.. men man vinner så mkt tid på att köra med OR-mappers än att själv hämta med ADO.Net och mappa mot entiteter.. samt att man får massa trevliga och bra features från en OR-Mapper, så som Identity Map, Unit of Work, Change tracking etc.

Jag är förtjust i MVP och MVC pattern, så i WIndows apps skulle jag tex valt att implementera MVP pattern, där Presenters går mot Repositories för att hämta upp entiteter.. ev så skapar jag ett applikation/service lager, så mina Presenter går mot det lagret som i sin tur går mot Repositories.

Om du har en väldigt liten app, där du inte behöver bry dig så mkt om underhåll och där den inte kommer att öka i storlek, samt har väldigt få användare och Win Forms, så tycker jag inte du behöver blanda in DDD om du inte vill. spec inte om du vill få klart appen så fort det går. Jag skulle iofs valt DDD med det är för att jag är van att jobba med det..

Alt 2 och 3.. Skapa rellationer i databas med nycklar är det man gör.. som du säkert vet.. allt beror på hur stor appen är, hur många användare, hur du vill att den ska skala etc.. Om Alt 2,3 är väldigt liten, så se på mitt svar om alt 1..