Ni som förespråkar repositories i stället för att låta ett objekt kunna tillhandahålla relaterade objekt, anser ni att DOM gör fel som har metoder för att komma åt barnnoderna?

(Jag vet att detta är ".net - arkitektur" men jag hittade inget annat arkitekturforum och de andra diskussionerna har förts här.)

fast nu har du missupfattat, objekt får absolut visst tillhandahålla relaterade objekt..
bara att man undviker att exponera relaterade _filtrerade_ obejkt från entiteterna..


entiteterna exponerar ut datan i rå form, all filtrerad form sker via tex repos..

Det här kommer ju från disskusionen om inga metoder enligt DDD.

Man får absolut ha Getters och Setters, vilket i C# blir properties. Men du ska inte ha ngn storage relaterad logik i dem.

Vad är storagerelaterad logik? Kan du ge exempel på vad som är okej och vad som inte är det?

fel:

public Order GetOrder()
{
Connection conn = new Connection yadda yadda
sql = "select * from order where orderid = " + this.orderid.tostring();
hämtadatafråndb yaddayadda
Order order = new Order(datatable);
return order;
}


ok:

public Order Order
{
get{ return this.order; }
set { this.order = value; }
}

<b>fast nu har du missupfattat, objekt får absolut visst tillhandahålla relaterade objekt..
bara att man undviker att exponera relaterade _filtrerade_ obejkt från entiteterna..</b>

Interfacet Element tillhandahåller metoden getElementsByTagName(name). Är inte det en filtrering?


Hur är det med denna då? Är denna tillåten?

class Customer {
     public Order[] GetOrders()
     {
          return OrderStorage.getOrdersByCustomer(this);
     }
}

Det finns ingen absolut sanning.. det finns bara åsikter om vad dom är bättre och vad som är sämre..
Vissa åsikter håller man med om, andra inte..

"Ni som förespråkar repositories i stället för att låta ett objekt kunna tillhandahålla relaterade objekt, anser ni att DOM gör fel som har metoder för att komma åt barnnoderna? "

Det var en fråga om en specifik modell. Inte en allmän fundering.

"Det finns ingen absolut sanning.. det finns bara åsikter om vad dom är bättre och vad som är sämre..
Vissa åsikter håller man med om, andra inte.. "

I bland handlar det om att göra det svårt eller lätt för sig också....

<b>I bland handlar det om att göra det svårt eller lätt för sig också.... </b>

Det är just att göra det lätt för mig som jag tycker att jag gör om jag lägger in vissa metoder (annat än bara getters och setters) i en klass.

Per:
Finns ingen som säger att den inte är tillåtatet, men det är inte helt designmässigt rätt. Normalt så borde det var GetOrderLines på sin Order och att GetOrders ligger i OrderRepository som är källan mot dess Storage.

Order[] orders = orderRepository.GetOrders();

foreach(Order order in orders)
IList<OrderLine> orderLines = order.GetOrderLines();

Ovan kod ligger ex i Applikationslagret.
OrderLine och Order kan ma exponera upp i UI lager för presentation.

Mvh Johan

Hur bör då filtrering utifrån kund göras? Det gör du ju inte i koden du visar, Johan.

Order[] orders = orderRepository.GetOrders(customer);

Per, den stora skillnaden i DOM vs Entiteter är att DOM är en komplett in mem struktur.
alla noder finns redan i minnet när man jobbar med ett DOM träd.

man kan lätt accessa undernoder kors o tvärs utan att blanda in någon dataaccess av något slag, allt är redan laddat och initerat.

så är inte fallet med entiteter (oftast)
där av behovet av tex Lazy load.

anledningen att man inte placerar dataccess koden direkt i entiteterna är enbart för att det blir lättare att veta var saker går fel.

är det så att något med dataaccessen strular i DDD så kan man lätt hitta rätt ställe genom att börja leta i sin repo för en viss klass.

du skulle absolut kunna ha dataaccess i din entitet, men i ett stort projekt med mycket affärslogik etc , så finns risken att dina entiteter blir väldigt bloatade.
det är lättare att felsöka flera små klasser med få ansvarsområden än få stora klasser som gör lite av varje.

det är hela anledningen till att man separerar det.

//Roger

Skall presentationslagret behöva bry sig om var noder i en trädstruktur (t.ex. XML) lagras?

Och måste verkligen DOM vara "in mem"? Skulle inte DOM kunna vara "lazy load"?

DOM kan säkert lösas med lazy load men med samma problem som i entiteter , du får kladdig och bloatad kod i nodklassen.

jag tror du hakarupp dig för mycket på att det skulle vara någon magisk anledning eller något mer korrekt oop sätt att göra på ena eller andra viset.

det handlar bara om att kunna hitta rätt ställe när man felsöker i stora projekt.
precis av samma anledning som man delar upp sin kod i flera filer istället för en enda stor megafil.

Precis som roger säger så handlar det om begreppet "separation of concerns" och en av de separationerna är att separera domänlogik (bussiness) från ren storage (spara/ladda från en persistant storage).

Man gör det dels för anlednginar som Roger nämner, dvs för att dela upp systemet i mindre och lättare delar att hantera och felsöka. Men man gör det också för att det skall vara enkelt att ändra på antingen affärsreglerna eller storage delen utan att för den sakens skull vara tvungen att gå igenom och röra hela projektet utan du kan koncentrera dig på de små lättrörliga repositories som finns.

Det ökar också "testability". Du kan nämligen enkelt testa din domän fristående från databasen eftersom den är en sperat del.

"Skall presentationslagret behöva bry sig om var noder i en trädstruktur (t.ex. XML) lagras? "

Hur menar du att presentationslagret måste bry sig om vart lagras bara för att du använder repositories? Du abstraherar ju bort lagringsplatsen vilket som.

Roger Johansson skrev:
<b>Per, den stora skillnaden i DOM vs Entiteter är att DOM är en komplett in mem struktur.
alla noder finns redan i minnet när man jobbar med ett DOM träd.

man kan lätt accessa undernoder kors o tvärs utan att blanda in någon dataaccess av något slag, allt är redan laddat och initerat.</b>

Detta tolkade jag som att det var för att noderna redan ligger i minnet som det är okej att ha metoder för att komma åt undernoderna i DOM:

var subElements = currentElement.getChildElements(); // inte riktigt hur det fungerar i DOM, men ungefär.

Hade de legat i en databas hade det inte varit okej, utan då skulle man ha hämtat dem från en repository:

var subElements = document.getElementByParent(currentElement);  // document fungerar som en repository i DOM

Alltså, om noderna ligger "in mem" så skall man skriva på ett sätt, men om de ligger i en databas skall man skriva på ett annat sätt. Och detta behöver alltså ett högre lager (applikations- och/eller presentationslagret) känna till, därav min fråga:

<b>Skall presentationslagret behöva bry sig om var noder i en trädstruktur (t.ex. XML) lagras?</b>

Per:

Nu är väl DOM ett lite dåligt exempel då det egenskap är just att det laddats in i minnet o detta ex via en Repository. Annars beslriver du typ en LazyLoad hantering..

mvh Johan

DOM är en modell för att komma åt noderna i ett träd. Det finns väl inget i DOM som säger att hela trädet måste vara inladdat i minnet?

Men jag förstår inte riktigt vad det är du är ute efter ( ? )

Det kommer absolut inte komma någon arg gubbe o plinga på dörren om du gör på ena eller andra sättet.

Du har ju fått svaren på varför man gör separationen.
Underhåll och Testbarhet.

Det är allt , no more no less.

Hela tänket går ju hand i hand med dependency injection/IoC, återanvändbarhet och testbarhet.

Man designar sina klasser på ett sätt så det är lätt att unittesta dessa genom att injecera dependencies utifrån eller att helt hantera vissa saker utanför klassen.
På så sätt får klassen i fråga bara en/få uppgifter , tex i entiteternas fall: representera data i typad form.

Och man kan lätt testa så klasserna fungerar som det är tänkt utan att blanda in databaser etc.


dina entiteter används förmodligen i princip av hela din applikation, och om då entiterna är frikopplade från dataaccess etc, så kan man direkt testa stora delar av applikationen.

Du kan tex i dina tester använda mockobjekt för tex repos/factories som lämnarfrån sig testdata.

Så även om du kanske inte testar 100% av din riktiga repo, så blir iaf allt annat testat.

Skulle persistenslogiken ligga i själva entiteterna så skulle du förmodligen bli tvungen att ha mockobjekt för alla entiteter eller ev köra testerna mot en testdatabas.

anledningen att man ogärna vill testa mot en riktig db är att det tar tid och databasen måste fyllas med rätt data innan testet körs.

Men tycker man inte det är ett problem eller om man skiter i att testa alls, så går det absolut bra att bygga precis hur man vill.

Nu är just DOM ganska lätt att testa i normala fall pga att det _är_ en in mem struktur i alla de fall där jag träffat på DOM.

<b>Men jag förstår inte riktigt vad det är du är ute efter ( ? )</b>

Jag vill förstå, och för att förstå måste man våga ifrågasätta. Och den stora frågan för den här tråden var om ni inte anser att DOM bryter mot reglerna i DDD.


<b>Hela tänket går ju hand i hand med dependency injection/IoC, återanvändbarhet och testbarhet.</b>

Jag ser inte varför man inte skulle kunna ha dependency injection och lagringsrelaterade metoder i en entity samtidigt.


<b>anledningen att man ogärna vill testa mot en riktig db är att det tar tid och databasen måste fyllas med rätt data innan testet körs.</b>

Detta förstår jag och håller absolut med om. Men kan man inte lika gärna låta en entity returnera mock objects för relaterade objekt i stället för att låta en repository returnera dem?

Men DOM bryter ju inget.

DOM är mer eller mindre en infrastructur grej och ett mönster för att lösa ett problem.
Ex säg att du har en Order med massa orderrader o dessa hart en artikel.
Så kanske du från din order vill veta om du har en viss Artikel då kan du enkelt typ skriva.

Order.HasArticle(article)

eller

Article article = Order.GetArticle(articleID);

Om du har ett krav som kräver att du måste ha denna funkton typ som GetElemets...

Pga prestanda skäl har man LazyLoad som ett mönster. Det bryter lite mot vissa ev OOD tankar kan tyckas, men ett nödvändigt ont ibland. Ex så kanske din Order har flera tusen orderader som är för krävande att ladda in med en gång då kör du ju LazyLoad på dn Order.OrderLines...

Här kan du ju enkelt använda AOP eller andra olika transparante mönster för att ev slippa ha kod i din OrderLines som gör din LazyLoad för komplex.

Se Rogers NPersist med lazyLoad stödet hur det fungerar. Riktigt snyggt...

Man bör oxå förstå att DDD är mer ett tanke sätt med vissa mönster man kan fölsja för att hålla sin model konsist men andra designmönster och tekniker är ju självklart välkomna i de lägen där de måste existera.

Mvh Johan