Hej,

Vi utvecklar nu ett intranät som skall hantera väldigt stora mängder av användare och främst bilder. Själva upplägget kan väl liknas med en community. Det är väldigt viktigt att det hela beaktar bästa möjliga prestanda samt bästa möjliga återanvändning av kod. Idagsläget skall sajten vara för webb men i framtiden planeras den också att lanseras för mobil på något sätt.

Jag har tidigare utvecklat i n-tier och känner att jag förstår den tekniken ok men jag vill utreda vad som passar bäst, vilka steg som skall tas bort etc.

Det som jag upplever är svårt är att hitta strukturen på allt själv. Jag är ute efter att få se t.ex. mappstrukturer, namespace, filnamn etc. Det som vi har tittat på nu är följande:

I t.ex. User-metoderna som hanterar kontoinställningar etc.
- User : Fungerar som vanlig BLL med hantering av business rules samt anrop mot DAL.
- UserDB: Fungerar som vanlig DAL men vi har valt att skippa möjligheter att använda andra DB-
providers än SQL.
- UserObject: Transportobjekt med properties för alla fält i User-tabellen. Userobjektet skickas ifrån
UserDB till User och ut till PL. Detta objekt kan då också skapas som en generisk lista.

Om ni har sett real-life projekt som är vettiga (Jag bedömmer t.ex. DotNetNuke-strukturen som för komplext för oss).

All information om hur jag ska gå vidare är relevant.

MVH
Robert Johansson

Jag har använt en liknande arkitektur i ett par projekt nyligen. Skiktar upp det på ungefär samma sätt som du men med lite andra namn och lite annan logisk struktur. Använder namespaces för att säkerställa att UI inte når DAL osv. I ditt fall skulle det se ut ungefär så här (Vi kallar projektet "Robert"):

Namespaces (=lager):

Robert.UI - aspx med codebehind
(fil/klassnamnexempel: UserRegistration.aspx/UserRegistration.cs)

Robert.DOM - Domänlager med rena C# objekt (POCO's) Tex User med fields och properties "databärare" som nås från alla lager, jag brukar säga att det löper vertikalt vid sidan av de övriga lagren.
(fil/klassnamnexemel: User.cs)

Robert.BLL - Businesslager som innehåller businesslogik och agerar även "manager" eller "service" mellan UI och DAL. Många webbaplikationer blir ganska databasintensiva så ofta innehåller dessa rena "interfaces" (ja jättedålig jämförelse men men) mot DAL-metoderna.
(fil/namnexempel: UserManager.cs)

Robert.DAL - Databaslager (påminner om Data Access Object pattern från J2EE patterns) klasser med databasmetoder, returnerar aldrig databasspecifika typer (sqldatareader, dataset osv) utan endast bastyper, objects samt objectcollections (generic Lists). Här man man välja att implementera databasaccessen själv eller nyttja MS Data Access Application block (SQLHelper) som jag tycker funkar suveränt bra, kolla in det om du inte gjort det!
(fil/namnexempel: UserDAO.cs)

Sedan lägger jag till en Genricklass i resp DAL och BLL-lager som kan hantera en del applikationsgemensamt som strängformattering, hämta ut en connectionstring osv. (BLLGeneric.cs/DALGeneric.cs)

Detta är grunden, man bör fundera på att använda någon form av Factories (kanske Spring.NET) eller liknande för att hantera instansiering för att slippa instansiera konkreta klasser överallt för framtida underhåll.

Jag tycker att man får en helt ok struktur och överblickbarhet med detta tänk. Sen tillkommer det "vanliga" OO-tänket med lös koppling mellan klasserna osv.

puh! det blev lite långt men det blir ju lätt det när man beskriver sånt här :-)

Hoppas att det kan ge någon slags input, och jag tar själv jättegärna emot lite feedback på det jag skrivit också från andra också!

PS. Jo mappstruktur, under App_Code (har utgått från att du kör .NET 2.0) skapar jag jag 3 mappar: /DOM, /DAL och /BLL där respektive filer ligger för att få struktur även där. UI-filerna ligger i applikationsroten och eventuella undermappar (tex /admin) som vanligt, bilder i egen mapp osv osv som alla andra webbappar.

Här haglar responsen tätt....

Jag tyckte det såg ganska bra ut

Man skulle ju kunna lkägga DOM, BLL, DAL i egna assemblies för att förtydliga seperationen mellan dem, och för framtida vidareutvecklingar.

DAL lagret är ju extremt viktigt att lägga mycket tid på om det skall bli en högprestanda applikation.

En del av ditt SQLServer-baserade system bör absolut vara Stored Procedures. Ett utmärkt sätt att separera SQL-queries från OOP, det ger både tydlighet och återanvändbarhet. Samt bättre prestanda.

"bättre prestanda"
Det här har inte stämt sen SQL Server 7. Pga cachningen av exekveringsplan på de första parametrarna som skickas in så kan tom SPs prestera sämre än ad-hoc queries idag då de optimerat hanteringen av dem enormt.

"Ett utmärkt sätt att separera SQL-queries från OOP"
Ett bättre sätt är att inte hanter SQL överhuvudtaget utan låta ett ramverk göra det åt dig. Ex NHibernante, NPersist, LBLGenPro.

En viktig tanke gällande SPs om de nu skall användas är att se till så de verkligen bara utför CRUD.
Dvs det är sååååååå himla lätt att slinka in med saker som bör placeras i ens businessobjekt...
Latheten kan lätt ta över att hoppa över struktur... Workarorounds blir ett faktum och Pang spagetti o oreda.

Så mitt tips är ta fram en guideline, beskriv vad de olika källorna skall ha i uppgift vad de skall göra och inte får göra, detta för att få en bra struktur i sin kod. Detta även om det kanske låter knasigt kan även leda till bättre prestanda då man faktiskt enklare kan hitta flaskhalsarna och få en första idé vart flakshalsen kan ligga... m.m. Sedan ger det ju bättre kvalité och förändringsbarhet att följa en guideline strikt.

Focusera heller inte för mkt på prestanda i början, många lägger ner ca 80% på allt de kodar så det är så optimerat som möjligt helt i onödan. Spara dessa 80% så når man sin deadline snabbare... Samt det är först när man "är klar med kravet" som prestandatester gör sin nytta, dvs kommer jag klara det prestandakrav jag har? I många fall underskattar vi datorn krafter för det känns fel. Teori och prestanda är inte samma sak som praktiken o prestandan luras inte av att det känns snabbare att göra si än så för oj så fel det kan bli även om det logiskt känns rätt.

Fokusera heler inte så mycket på databaen utan koden och modellen. det är viktigare att ha en kod som är självbeskriven som är lätt att förstå för återanvändbarhet m.m. Databas bör bara ses som en storage av data inte som ett krav på hur applikationns objekt skall se ut. Det är databasen som skall anpassa sig efter ens modell och inte tvärt om vilket många oftast tror...

Mvh Johan

<b>
Det här har inte stämt sen SQL Server 7. Pga cachningen av exekveringsplan på de första parametrarna som skickas in så kan tom SPs prestera sämre än ad-hoc queries idag då de optimerat hanteringen av dem enormt.
</b>

Lite spekulation:

Det gäller väl i princip bara SELECT frågor, då den kan cacha resiultatet.

För insert, update och delete tjänar man väl fortfarande på att använda sp?

Nej det gäller i princip all query exekvering mot sql server.

Jag har inte det spefika i huvudet själv, men jag har fått det mässat för mig av våra SQL instruktörer länge nu.

Det small till med svar här. Riktigt intressant att se. Då vi utvecklar större webbapplikationer så tycker jag det är viktigt att inte köra fast på ett spår utan hela tiden utvecklas.

Om man tittar på Microsofts PetShop, vad har ni för kommenterar på den. Vad är bra, vad är dåligt?
De använder ju ej SP, utan ad hoc t.ex.

MS Petshop är ett typ exempel på vad som händer när man siktar på skalbarhet och prestanda istället för enkel utveckling i början.

Ett bra system måsta nästan alltid ta en initial cost vad gäller utvecklingen för att nå långsiktiga mål.

Patrik L.. angående bättre prestanda:
http://www.sql-server-performance.com/stored_procedures.asp

"Att inte hantera SQL alls" finns inte på min karta.. :)
Jag har inte sett någon autogenerator som kan skapa tillfredställande SQL för en korrekt, normaliserad relationsdatabas. Men det klart om man betraktar relationsdatabasen som en lagringshylla för autonoma objekt då kanske det blir helt OK SQL. Vi bygger inte system så. Vi väljer i stället att utgå från den i särklass bästa tekniken som existerar för att hantera data, nämligen relationsdatabasen.

Johan Normén: "Fokusera heler inte så mycket på databaen utan koden och modellen. det är viktigare att ha en kod som är självbeskriven som är lätt att förstå för återanvändbarhet m.m. Databas bör bara ses som en storage av data inte som ett krav på hur applikationns objekt skall se ut. Det är databasen som skall anpassa sig efter ens modell och inte tvärt om vilket många oftast tror... "

Jag tycker tvärtom. Fokusera på relationsdatabasen och SQL så får du ett bra system "på köpet".

Varför "TROR" du att det är klokt att ignorera den magiska kraften som finns i relationsdatabasen?

Intressant artikel,

jag skall när jag får kontakt med våra SQL lärare skicka in ett par länkar som argumenterar för det exakt motsatta.

Vad gäller relationsmodellen, jag säger på inga sätt att den är dålig. Men den är framtagen och byggd runt teorier för LAGRING av data. Inte för att så effektivt som möjligt fånga en domän.

Ta exemplet foreign keys och primary keys. Var i domänen används de? Sällan gör de det. De har nästan alltid ett id för lagring och ett för bussiness användning. (tex om du använder en GUID, vart i företaget kommer du se den igen?=

Jag tycker att modell och domän brukar gå rätt väl hand-i-hand.

Då frågar jag igen.

IDt du använder för persist, vart använder användaren den?

Jag skrev "rätt väl", inte exakt.

ID motsvarar pekare/referenser i programkod, vilket i sin tur svarar mot associationer i domänen.

Ja jag vet hur tekniken fungerar, men de säger ingenting för affärsreglerna eller affärslösningen.

En ren domänmodell kan du visa för domänexperterna och där finns inga frågetecken runt vad ett visst attribut är. Alla termer i en sådan kan mappas direkt mot affärsdomänen.

Relationsmodellen är optimerad för att lagring skall bli så optimalt som möjligt, i många fall måste du ta beslut i relationsmodellen som inte har ngn som helst logisk motsvarighet i affärsmodellen och det leder till många konstigheter i koden ur ett affärsperspektiv. Ett typ exempel är "kopplingstabeller" som ur ett normaliseringsperspektiv är klockrent. Men i de flesta affärsmodeller har de ingen motsvarighet.

En bra och ren modell kan användas som ett kommunikationsunderlag med de som kan affären bäst. Relationsmodellen kräver översättning från teknik till affär av den som visar den.

Missupfatta mig inte nu, jag tycker att relationsmodellen är bra. Min poäng är att dess styrka är effektiv lagring och effektiva frågor från lagrad data. Inte modellering av affären.

<b>i många fall måste du ta beslut i relationsmodellen som inte har ngn som helst logisk motsvarighet i affärsmodellen och det leder till många konstigheter i koden ur ett affärsperspektiv.</b>

Men hur stort problem är det? Domänexperterna har sällan anledning att se koden eller databasen.

det är ett problem eftersom du inte fångar domänen i koden, du skriver kod som inte mappar mot problemet du vill lösa. Dessutom, en ren domänmodell kan du direkt plocka fram en grafisk representation över och visa för din affärsexpert och använda som kommunikationsgrund.

Ju närmare applikationen du tar affärsexperten och vice versa, desto större chans har du att inte missar ngt kritiskt.

Eric Evans har ett bra kapitel om just det här i sin bok Domain Driven Design.

Inom datamodellering pratar vi om en grov datamodell som sedan utvecklas till en detaljerad datamodell. Den grova datamodellen skall beskriva vilken information som ska hanteras samt hur denna information hänger ihop, den är därmed en lösning på problemet att hantera information. Den innehåller inte kopplingtabeller (M:M relationer).
Själva kärnan i system och systemutveckling (av Informationssystem) tycker jag bör utgå från behovet av att hantera, och strukturera information. Alltså centrerat runt själva datat och datamodellen. Relationsmodellen och databasen ger oss den bästa möjligheten som hittills är känd för att lösa detta. Hur koden ser ut (OOA/OOP) är en annan historia. En snygg modell för koden finns ju bara för att underlätta för oss som programmerar, källkodens struktur har ingenting att göra med verksamhetens behov av att strukturera information. Det är bara ett hjälpmedel för oss som ska lösa problemet. Jag tror att vi utvecklare ofta blir hemmablinda, vi försöker lösa problemet som vi har med att lösa problem. Alltså vi försöker underlätta för oss själva. Och då kanske vi glömmer bort att lösa det verkliga problemet, som inte var att underlätta för oss själva, utan att underlätta för verksamheten.

Ja det var så man tänkte förr.

Men man har sett att lagringen av datat inte får vara centralt och att en kontinuerlig kontakt och kommunkation med beställaren elimenerar rena fel ur ett affärsperspektiv. Relationsmodellen är inte ens sådan modell som man kan kommunicera med affärsspecialister.

En OOD modell kan man det däremot med. Igen, jag säger inte att relationsmodellen inte har sin plats, den beskriver, precis som du säger, datat och hur det lagras. Men när det kommer till hanteringen av datat och att så effektivt som möjligt fånga affärsmodellen och sedan kontinuerligt kunna kommunicera den, då är relationsmodellen keff. Det var en av de bidragande anledningarna till varför objektorientering överhuvudtaget togs fram. Den andra var för oss programmerare, men det var inte det enda huvudskälet.

Poängen är att relationsmiodellen är för datalagring, objektsmodellen för att fånga affärsinformationen, processer och hantering av desamma. Ytterligare en poäng är att ett system växer effektivast fram genom att du kommunicerar hur du fångar komplexiteten i affärsproblemet. Om du kan visa en bild för affärsexperterna över hur du "ritat" deras affär i kod, då kan de genast se om du förstått. En relationsmodell är inte ultimat för det.

Ngt som många har svårt att släppa är att även om lagringen har stor betydelse, så får det inte vara centralt. Det måste vara lösnignen som är central. Om du upptäcker att relationsdatabsen är det ultimata lagringsmediet för dig, då är det rätt. Men i ärligehetens namn, att ta det beslutet först innan man fått en modell att börja kommunicera med är tjänstefel.

Man får inte heller tro att en "big up front design" kommer att hålla. I små system kanske den gör det, i större så är det för mycket detaljer som inte kommer fram förräns man har en bild att kommunicera med.

Läs gärna:
http://domaindrivendesign.org/articles/blog/evans_eric_ddd_and_mdd.html
http://patternshare.org/default.aspx/Home.DDD.UbiquitousLanguage
http://www.jnsk.se/weblog/posts/ulreflections.htm

Böcker på samma ämnen:
http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/sr=8-1/qid=1166399029/ref=pd_bbs_sr_1/105-5509584-1058839?ie=UTF8&s=books
http://www.amazon.com/Applying-Domain-Driven-Design-Patterns-Examples/dp/0321268202/sr=8-2/qid=1166399029/ref=pd_bbs_sr_2/105-5509584-1058839?ie=UTF8&s=books
http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/sr=8-3/qid=1166399029/ref=pd_bbs_3/105-5509584-1058839?ie=UTF8&s=books

Ola:

>Jag tycker tvärtom. Fokusera på relationsdatabasen och SQL så får du ett bra system "på köpet".
Vad är ett bra system på köpet när man focuserar på SQL?
Är det relationshanteringen du anser att man får på köpet? För mig så är det bara Storage hantering man
får på köpet inget annat.

>Varför "TROR" du att det är klokt att ignorera den magiska kraften som finns i relationsdatabasen?
Jag sa aldrig att man skall _skippa_ den magiska kraften. dvs relationshanteringen och indexeringen...
Dock skall _inte_ databasen få bli focus för ens applikation för det är inte databasen som bestämmer applikationens gränser utan applikationen som bestämmer databasens.
Dvs.

Ta fram use case, user stories, mappa dessa mot en objekt modell. Me dhjälp av TDD impelementerar man sin objektmodell där efter skapar man en Storage del för objektens tillståndsdata. Ex. då en Relationsdatabas då den i dag är snabbare än en objekt databas pga sin Query och just relations teknik.

När något extra måste till är det fört i objekten man implementerar detta extra, om man då även behöver spara ner data för detta extra lägger man till det i db för storage...

Har arbetat i 100-tals projekt fär man focuserade på databasen o mappa sina krav direkt till en DB o inte till objekt o affärsmodell. Det skapade oftast problem 95 fall av dessa 100. Ju större projektet var ju fler problem. Workarrounds som ledde till spaggeti, Logik i SPs för att man låste sig då man inte utgivk från sin objektmodell m.m. 99 av dessa 100 fall hade affärsregelskod i SPs. O lilla justering var tvungen att göras inte bara i dbn utan i massa SPs för att slå genom till applikationen... Rätt normalt att det blir så när man fokuserar på DB... Men måste dock inte... Finns de som är bra på att se en objekt modell o tänka bra relations mappning... Men de är inte många...

Patrik har även gett en del bra svar som bara skulle göra mig upprepande...

Ola2:

>Alltså vi försöker underlätta för oss själva. Och då kanske vi glömmer bort att lösa det verkliga problemet, som inte var att underlätta för oss själva, utan att underlätta för verksamheten.

Är inte Tänka datainformation först, just att underlätta för verksamheten? Så uppfattar jag dina argument. Jag har nog aldrig vart med om ett projekt där information är steg ett... i en utv-modell...
...dock att steg ett ger svar på infomation som vi kan behöva...

Mvh Johan

Jag håller med lagringen skall inte ha för stor påverkan på arkitekturen av programmet.
Om nu lagringen är en databas så kanske den i ett senare skede kommer att bytas ut till t.ex. en Webservice eller något annat, då är det inte bra om man byggt in sig på att allts kall fungera runt en SQL baserad databas.

Det finns många böckers om det har länkats till tidigare som skriver om just detta.

Jag kommer från skolan, UseCase, Objektmodell osv...

Patrik: [Men man har sett att lagringen av datat inte får vara centralt och att en kontinuerlig kontakt och kommunkation med beställaren elimenerar rena fel ur ett affärsperspektiv.]

Men det ena har ju inte med det andra att göra.
Att beakta hur data bör organiseras motsäger inte kontinuerlig kontakt med beställare.
Relationsdatabasen är en abstraktion av den tekniska lagringen, det är alltså inte själva datalagringen av ettor och nollor på en teknisk nivå som man tittar på.


Patrik: [ Relationsmodellen är inte ens sådan modell som man kan kommunicera med affärsspecialister. ]

Vi har lycakts kommunicera grova datamodeller till kunder med bra resultat.
Det räcker att de har huvudet på skaft och är införstådda i vad man vill ha hjälp med.
Det är ju perfekt enligt min erfarenhet om man kan vara överrens med kunden om en datamodell,
vilket förutsätter att de begriper den. Men det tror jag att de flesta kan göra med lite hjälp på vägen.
En grov datamodell är inte "rocket science". I de projekt där vi har lyckats med detta så har vi sedan inte behövt ändra i datamodellen och vi har endast haft triviala buggar i de färdiga systemen.

Patrik [ En OOD modell kan man det däremot med. ]

Nja... OOD beskriver hur du ska skriva koden. Det struntar väl slutanvändaren i.. ;)

Patrik: [Ngt som många har svårt att släppa är att även om lagringen har stor betydelse, så får det inte vara centralt. Det måste vara lösnignen som är central. Om du upptäcker att relationsdatabsen är det ultimata lagringsmediet för dig, då är det rätt. Men i ärligehetens namn, att ta det beslutet först innan man fått en modell att börja kommunicera med är tjänstefel. ]

Jag tycker det är tjänstefel att strunta i SQL / relationsmodellen när man bygger informationssystem...

Jag argumenterar absolut inte emot DDD/OOD. Utan jag vill bara slå ett slag för relationsdatabasen.
Vi har i alla fall lyckats bra med våra system som är designade runt relationsmodellen OCH OO A/D.
Alltså en kombination av dessa metoder tror jag är bäst.

Johan N:
[ Vad är ett bra system på köpet när man focuserar på SQL?
Är det relationshanteringen du anser att man får på köpet? ]

Du får en korrekt hantering av information i informationssystemet på köpet. Det är väl trots allt syftet?

[För mig så är det bara Storage hantering man
får på köpet inget annat. ]

Då låter det på dig som att du inte alls är bekant med relationsmodellen..

[Jag sa aldrig att man skall _skippa_ den magiska kraften. dvs relationshanteringen och indexeringen...
Dock skall _inte_ databasen få bli focus för ens applikation för det är inte databasen som bestämmer applikationens gränser utan applikationen som bestämmer databasens.
Dvs. ]

Applikationens gränser är av mindre betydelse än applikationens hantering av information.

[När något extra måste till är det fört i objekten man implementerar detta extra, om man då även behöver spara ner data för detta extra lägger man till det i db för storage... ]

Då tror jag du riskerar dubbellagring av data, felaktiga data, dålig prestanda osv.

[Har arbetat i 100-tals projekt fär man focuserade på databasen o mappa sina krav direkt till en DB o inte till objekt o affärsmodell. Det skapade oftast problem 95 fall av dessa 100. Ju större projektet var ju fler problem. Workarrounds som ledde till spaggeti, Logik i SPs för att man låste sig då man inte utgivk från sin objektmodell m.m. 99 av dessa 100 fall hade affärsregelskod i SPs. O lilla justering var tvungen att göras inte bara i dbn utan i massa SPs för att slå genom till applikationen... Rätt normalt att det blir så när man fokuserar på DB... Men måste dock inte... Finns de som är bra på att se en objekt modell o tänka bra relations mappning... Men de är inte många... ]

Jo, jag håller med om att det kan bli väldigt rörigt om man försöker lösa allt i SPs.

Vi kan ta ett exempel. Du har en perfekt OOD som beskriver kunder och ordrar.
I början av projektet är användarna nöjda med att skriva in ett kundnr, klicka på sök, för att visa kundens ordrar. Din objektmodell med mer el mindre autonoma objekt som stödjer valfri "storage" fungerar perfekt. Du kan switcha mellan SQL-server, MySQL, och textfiler om du så vill. "Jättebra". Sedan ändras kraven. Och mängden data. Efter två år har man 75.000 kunder och 250.000 ordrar i systemet. Nu vill man i stället ha en översiktlista på webben där det ska vara möjligt att bläddra bland samtliga ordrar som existerar i systemet. Listan ska visa Kundnr, Namn, Orderdatum, Ordersumma, osv. Ibland sorterat på datum, ibland på namn. (Rätt eller fel.. kunden kräver det...IRL)
Dvs en kombination av data från "object_KUND", "object_ORDER", "object_ORDERRAD" ....
(eller EN SQL-sats... :-))
Inser du problemet med att ta fram listan genom att koda ihop det med OOP?
Om du INTE löser det med relationer och JOIN i en SQL-databas så är det helt fel lösning som kommer resultera i grymt dålig prestanda. Att du har jätteakademiska objekt som ser jättefina ut är totalt ointressant för kunden som INTE kommer att bli nöjd med en OOD-lösning på "problemet" (det är inte ens att betrakta som problem om man tänker relationsdatabas....)

Att t.ex. byta ut lagringen till autonoma anrop till Webservices som hämtar ut XML_kunder, XML_ordrar, XML_orderRader... är en ganska elegant teori men det lär ju inte fungera..

Sitter hos kund så får ta det långa svaret sedan men.

En korrekt OO modell abstraherar bort joins, det innebär inte att den slutar använda joins när den ställer frågan.

Ola: [Applikationens gränser är av mindre betydelse än applikationens hantering av information. ]
Är den? Der är ju inte databasen som bestämmer vilken iformation som skall visas det är ju use caset och kraven som är applikationen som lånar ex SQLen för att hämta och lagra den information man måste ha.
På så vis är det ju applikatione som sätter kraven hur informationen skall hanteras.

[Ang avancerad sökning med massa poster argumentet]
Det trevliga är just att om det ex kommer till 250 000 poster och prestandan blir lite lustig så finns det
flera sätt att gå till väga i en trevlig OO värld.

måste bara säga att Joins får mkt väl användas i en OO värld.

1... Cache
2... Snapshot klasser med mindre info för just sökningsresultatet där ID sedan används
för att få fram mer detaljerad information.

Om alt 1 och 2 med OO ändå ger prestandaproblem så finns det inte så mkt att göra åt saken
då får man köpa kraftigare hårdvara... För vilken databärare du än använder så sker en viss mappning.
Dataset, Xml, Egna objekt...

Bara för att man har en Order som sedan har OrderRader betyder inte det att varje OrderRad måste göra ett eget uppslag för att det är en OO modell. Applikationens krav och icke funktionella krav bestämmer vilken väg man måste gå hur man skall presista. Lazy Load, full load, Joins etc...
MEN man bygger databasen efter ens modell och applikationens krav. Så jag ser inte varför OO i ditt exempel skulle ge problem? jag har då aldrig stött på att det blivit problem dock har det gått fortare att göra otimeringar efter den rena OO modell man har...

Återigen är databasen bara en storage av data som representeras i sin OO modell.
Med joins, med keys, med index m.m. spelar ingen roll.
Du har din Order tabel du har din OrderLine tabel du har din xRef tabell med OrderID och OrderLineID för att koppla relationen mellan Order och dess rader men i din OO har du Assocationer istället där behöver du inte bry dig hur datat är kopplat i din storage det är Repositories klassernas uppgift att ge dig det du söker och fylla dina objekt med data som tillhör dem baserat på olika criterier.

Mvhj Johan

Det är ju databasen som lagrar informationen trots allt. Och du kommer inte klara att lagra informationen på rätt sätt, i många fall, om du inte tar hänsyn till relationsmodellen.
Som i det exempel jag gav med kombination av data mellan normaliserade kund/order/rad-tabeller. Vid stora datamängder fungerar det inte i praktiken om du inte har en lämpligt designad relationsdatabas med smart SQL, riktiga index, och JOIN som kan ta fram rätt data på rätt sätt inom rimlig svarstid.

Att lösa prestandaproblem med cache introducerar nya probem. Cache är är inte live data utan gammal data. Det kanske inte är ok. Du måste hantera det. Och du måste skriva hela cachningsmekanismen för flera delar i systemet om du ska förlita dig på denna lösning. Det blir mer jobb och målet du ville uppnå med din DDD/OOD - att underlätta - och snabba upp utv.tid osv - löstes inte.. (jag säger inte att cachning är fel med att använda det som plåster på en dålig datamodell/dålig kod för dataåtkomst är inte bra!). Liknande problem med dina snapshotklasser - dubbelarbete plus introducerar en större och därmed mer komplex objektmodell. Att köpa mer hårdvara är inte ens applicerbart på diskussionen.

Jag har aldrig påstått att "OO" ger problem. Jag påstår att du får problem om du struntar i relationsmodellen och om du betraktar datalagring som storage av autonoma objekt.

Det är ingen som påstått att du skall strunta i relationsmodellen. Bara att den är för att effektivt lagra datat. Inte för att effektivt skapa en applikation där är det andra modeller som måste ta vid.

Du är så fokuserad på att SQL frågan är det centrala i en lösning. Det är det centrala för att ladda och spara data. Lösningen i sig bygger du i kod. Vart datat kommer ifrån och hur den delen effektiviseras, får inte påverka hur du bygger din färdiga lösning. Det är bara ett persistens media, inte hjärtat i lösningen.

Ett tydligt exempel i ett annat context:

Om du skall bygga en ordbehandlare så börjar du inte med att definera ditt filformat utan du tittar på vad du vill uppnå först. Sen när du närmar dig att du måste peristera dokumentet, då börjar du titta på hur du så effektivt som möjligt kan lagra det.

På samma sätt jobbar du i appliaktioner, du börjar titta på vad du vill lösa och hur du skall lösa det. När du börjar närma dig att du måste persistera från din domän, då tittar du på hur du så effektivt som möjligt kan lagra datat. Som jag sagt innan, så kankse man då tom kommer fram till att en SQL databas är overkill.

Ola.

Punkterna med chache m.m. var ev ett sätt att attackera prestandaproblem självklart är olika prestanda inriktingar beroende på system så jag vet mkt väl vad cache ger som fördel eller nackdel.
Men nog om det.

Återigen säger jag inte att du inte skall tänka relationsmodell när du väljer relationsdatabas.
Jag säger bara att man inte spegler relationsmodellen mot OO objekt utan tvärt om.
Det är först man vet vilka objekt och vilken data som skall presenteras som man går på db byggandet.
Dvs utifrån in än innifrån ut.

ex jag bygger min Order min Order har en Customer min Order har även OrderRader som i sin tur
har en Artikel...

När jag byggt upp dessa OO objekt o måste spara deras tillstånd i db o valet är en relationsdb så blir det.

Order tabel med sina kolumner, en OrderLine tabel som i princip är en relationskoppling mellan Order och Artikel. Order har relationskoppling md Customer.

Jag kan indexera, jag kan ha keys etc... Min relationsdatabas blir ren, den blir effektiv och bestämmer inte hur min kodmodell skall implementeras eller se ut...

Jag kör med CRUD så länge det går och mer avancerade TSQLer om jag måste vilket jag försöker undvika så länge jag kan... CRUDEns baseras på de krav min modell ställer och inget jag skapar före mon modell existerar. Jag kör Mockobjekt som leker DB källa tills mina testcase o mon modell lever i minnet som den skall sen ser jag till så min modells data kan lagras och bygger då min DB...
Beror lite på itterationers storlek, modulers löskopplingar etc...

På detta sätt kan aldrig min DB sätta krav på min modell utan tvärt om så som det skall vara.
Jag får alla prestanavinster en DB kan ge mig m.m. bara att jag inte tänker fel när jag bygger min db vars färändring kan ställa till det redigt med min modell som mappades från dbn o inte tvärt om...

Enda skillnaden är att krav mappas till OO modell och OO modell till DB och inte
krav till db som blir krav för sin OO modell.

Mvh Johan

Dvs, det blir applikationen och hur den fungerar som sätter kraven på hur lagringen skall skötas. På sätt blir inte lagringen de centrala i applikationen utan bara en del av den.