Jag har en simpel XML fil. Det jag funderar på är vad som är best practices i området när man hämtar data från XML fil i DAL och returnerar det till BLL för att fylla sina domän objekt. Jag kan från DAL returnera ett dataset/datatabell till BLL men finns det några andra bättre alternativ? En datareader fungerar väl inte när det kommer till XML? Hur brukar man göra?

Vad sägs om att ditt DAL levererar objekt? Vad är det för typ av data som ligger i xml filen?

Vad tänkte du att jag ska leverera för objekt? Jag vill helst inte att mitt DAL ska känna till mina domän objekt. Det känns också lite överdesign att skapa egna objekt där deras syfte är bara att leverera data mellan DAL och BLL. I dessa fall skulle jag i så fall rekommendera att man använder dataset/datatabell istället. Men utveckla gärna vad du menar...

Jag har gjort ett enkelt minnesspel och det som finns i xml filen är spelresultat. Jag skulle dock vilja att min relation mellan DAL och BLL inte blir för XML knutet. För det ska tex vara enkelt att byta ut min datakälla så att det går mot tex en databas.

Om jag hade designat det så hade det funnits en klass som sköter inläsandet av data från xmlfilen och skapar t.ex. GameResult objekt.

GameResultRepository bör få reda på filsökvägen via konstruktor, inställningsfil eller dylikt.

IList<GameResult> gameResults = GameResultRepository.GetAll();

IList<GameResult> gameResult = GameResultRepository.GetByGame(game);

Jag tycker att ditt DAL bör känna till affärsobjekten.

Jepps..

Tycker också att ditt DAL bör känna till affärsobjekten. Utövar liknande princip som Niclas tar upp...

Instämmer med övriga om att DAL bör känna till affärsobjekten.

Vad gäller Xml -> Affärsobjekt så kan du kolla om Linq to XML funkar (går åtmindstonde sökningarna busenkla).

Repositories ;-)

Det sköna med Repositores (DDD) är att de själva känner till Domän Objekten och DAL men nyttjar bara DAL för att hämta dess tillstånd medans Repositories har i uppgift att fylla objektens tillstånd.

På så sätt kan du ha ditt DAL fritt från Domän kunskaperna och låta dina Repositories som är en del av Domänen känna till domänkunspaer och Databäraren.

DOMÄN -> Repositories -> DAL

Detta är bla en av många saker som gjorde att jag gilla DDD man slipper dina bekymmer allt finns där :)

Mvh Johan

Och om du vet att det kan bli aktuellt att byta från Xml till någon annan form av persistens så kan du se till att skapa interface för dina repositories, ex. IGameResultRepository (vilket ju även är bra om du kör TDD och vill mock:a dina repositories).

Så kan du bara skapa lite olika implementationer beroende på vart du vill lagra datat.

--> Johan
Jag använder mig av en GameResultRepository och den har bland annat en metod som heter GetAll(). Denna metod returnerar en lista av spel.

Det som jag inte vill är att min Repository ska känna till vad det är för typ av datakälla som jag använder. Därför vill jag inte returnera från mitt DAL tex en XMLreader eller något liknande. Det blir för knutet till en viss typ av datakälla. Det ska vara något generellt såsom en daareader (verkar dock inte fungera för XML filer) eller ett dataset/datatabell. I dagsläget returnerar jag från mitt DAL en IEnumerable<DataRows>. Finns det något bättre att returnera så hör gärna av er!

Sedan har jag en liten fundering kring detta med att inte låta DAL känna till domänobjekten. Jag vet att du är för det och att de flesta förspråkar just en sådan arkitektur. Men det som jag inte gillar med att DAL inte känner till domänobjekten är att metoderna kan bli onödigt komplexa. Add(game) känns tex mindre komplicerad än en metod som tex Add(game.x, game.y, game.z etc). I vissa fall kan det bli väldigt många inparametrar.

Så jag känner mig lite splittrad :) Men det kan kanske beror på att jag inte fullt ut förstått varför domänobjekten inte bör vara åtkomliga i DAL. Kan du eller någon annan förklara det för mig?

--> Niclas Pehrsson och Fredrik Malmström
Om jag förstått er rätt så förespråkar ni att DAL ska känna till domänobjekten. Johan Normén och många andra har en annan åsikt, dvs att DAL inte ska känna till domänobjekten. Jag är dock splittrad i frågan som sagt. Men vad är argumenten att DAL känner till domänobjekten? Finns det några nackdelar?

--> Andreas Öhlund
Vad tror du om att istället returnera en IEnumerable<DataRows> från DAL?

Det med att mocka har jag ännu inte testat på men det låter intressant. Det jag håller på med nu är ett litet testskott på lite olika tekniker, från Silverlight, WCF, DDD, TDD till Linq. Mockning skulle dock vara intressant att testa på i samma veva kanske.

Hängde inte alls med varför det skulle bli mer komplexa, det blir ju tvärt om då du har mer sepration.

Om du inte vill att dina Repositories känner till ditt DAL? (varför inte förstår jag inte) så är det bara att interface o hålla på.

Meningen med just repositories är att de bla skall ha koppling till sin källa medans repositories själva faktiskt kan använda interface för att mocka bort dem om man vill byta data källa.

Här kommer även LINQ in som en godbit. Du kan nyttja LINQ för att fylla dina objekt och detta då i dina Repositories eller i stödklasser till dem, allt basear på ändåmål och dina krav så det är svårt att säga gör si eller så.

Tänk på att DAL mer eller mindre egentligen är dina Data Access komponenter som sedan repisotiries nyttjar, de är databärare det är de som har i uppgift att ge den databärande typen till repositorien så den kan separera domän från DAL där repisotiry ex får en XDocumnet och mappar den till objektet som du sedan returnerar tillbaka. Det är repositoryn som sedan även tar emot objektet som den då läser av för att be DAL att spara.

Det viktiga är att se DAL som en kopplare till källan som returnerar bäraren av datat. Sedan ha Repositores som ett mellanlager mellan bärande datat och dess domänobjekt.

Mvh Johan

Instämmer med Johan. Jag tror att vi har olika definitoner av begreppen Repository och DAL. Jag försöker förtydliga med ett exempel.

Ungefär så här skulle jag lösa problemet:

1. Skapa ett interface som alla som vill komma åt GameResults jobbar mot.

public interface IGameResultsRepository
{
IList<GameResult> GetAll();
}

2. Låt oss säga att det finns krav på att kunna ladda dessa från både XML och nån form av DB. Detta löser vi genom att implementera interfacet med 2 olika klasser.

Xml:

public XmlGameResultsRepository: IGameResultsRepository
{

public IList<GameResult> GetAll()
{

XmlDocument doc = new XmlDocument("some path");
List<GameResult> results;

//loopa igenom alla noder och skapa en gameresult entitet som
//vi petar in i en lista, kan lösas enkelt med Linq to Xml eller manuellt


return results;
}
}



DB (i detta fall med NHibernate):

public NHGameResultsRepository: IGameResultsRepository
{

public IList<GameResult> GetAll()
{


var q = from gr in session.Linq<GameResult>()
select gr;

return q;
}
}

3. Sedan är det bara att välja den variant man behöver beroende på situationen.


I det fall man kör med mönstret "repository" så ser jag ingen vinst med att skapa ett "DAL" lager också då Repository-lagret redan abstraherat bort den infrastruktur som krävs för att spara och hämta data. Man kanske till och med kan säga att XmlDocument resp. NHibernate fungerar som DAL-lager i detta fall.

Vad säger du Johan är det nått i stil med detta som du syftade på?

Disclaimer:
1. Koden ovan lär inte kompilera då den är kodad i IE.7 :)
2. Detta upplägg funkar naturligtvis bäst då man använder sig ad Dependency Injection och någon form av IoC-container.

Andreas.

Ja typ... Sen kan man ju göra massa mer beroende på vad man har för andra krav på sitt system etc...
Men i stort sätt skulle jag börja på detta sätt.

mvh Johan