Hej jag har ännu en fråga om NHibernate, jag har kommit en bit med att kolla om den klarar av de krav jag har men nu har jag letat och funderat en stund med hur man skall lösa följande problem på ett bra sätt

http://img14.imgspot.com/?u=/u/07/185/07/example.jpg

Om man kikar på länken ovanför så har jag en tabell kalla Assignments den innehåller massor av uppdrag, i min modell så har jag Assignments som en basklass och sedan finns det i exemplet två stycken subklasser TaxAssignment och AuditAssignment.

Dessa bestäms av en integer som heter Type i tabellen Assignments.

Jag har insett att man kan skapa två xmlfiler som laddar AuditAssignment respeksive TaxAssignment och ladda dom var för sig, men jag skulle vilja kunna göra så att dom anropas in alla på en gång med ett anrop till databasen men ändå skapa dessa olika instanser av objekten.

Eller måste jag helt enkelt göra en Repository som först laddar alla Assignments och sedan alla TaxAssignments?

Jag hoppas jag lyckades skriva detta förståligt.

Om jag har förstått rätt så är de olika assignment olika entiteter i din domain-modell eller hur? I det fallet skulle jag skapar två Repositoeis.. MEN OBS! Om det är så att dom är aggregat till en annan entitet, så ska root entiteten's Repository ansvara laddningen av aggregaten. En annan sak.. tänk på att du kan tänka på KISS (Keep it simple stupid). Ibland får man lov att köra saker enkla och dumma ;)

/Fredrik Normén [MVP]
blog: http://fredrik.nsquared2.com

är du säker på att du behöver arv, räcker det inte med en "typ" flagga?

<discriminator column="persontype" type="String"/>

Jag tror detta löser problemet.

KISS det har jag haft med mig sedan Högskolan var en lärare som gillade det.
Värt att tänka på ibland ja :).

Visst är det skönt att lösa problemet själv!? ;)

Antar att du har läst denna artikel om just discriminator!?
http://www.theserverside.net/tt/articles/showarticle.tss?id=NHibernate


----

Nackdelen att använda en typ property är delvis att man i kod behöver titta på typen istället för att använda objektet med en gång.

text:

private List<Rental> _rentals;

public double Statement()
{
double amount = 0;

foreach(Rental rental in this._rentals)
{
switch(rental.Movie.Type)
{
case MOVIE.NEW:
if (rental.DayRented < 2)
amount += rental.DayRented * 30;
else
amount += (rental.DayRented * 30) * 1.5;
break;
case MOVIE.Original:
amount += (rental.DayRented*20);
....
}
}

return amount;
}

Om vi istället använder arv och lägger till interfacet GetCharged i Movie och skapar subklasser som tex NewMovie, OriginalMovie etc.. så kan vi i de olika subklassern lägga in prisberäkningen, då blir koden:

private List<Rental> _rentals;

public double Statement()
{
double amount = 0;

foreach(Rental rental in this._rentals)
amount += rental.Movie.getCharged(rental.DayRented);

return amount;
}

Genom att göra detta så har vi nu fått bort Switch satsen. Problemet som återstår är att priset och uträkningen ligger nu på filmen.. och en film kan bli gammal över tiden, så ska vi vara petiga så kan vi använda state pattern och inte lägga prisberäkningen i Movie utan i egna Pris klasser som vi kopplar till Movie istället. Gjorde en sådan lösning åt en kund för att räkna ut pricer för olika lastenheter etc. Men det jag ville visa är i alla fall att med arv kan vi få snyggare kod, än med en "typ" property. Men det beror självklart på hur objektet ska användas etc.

/Fredrik Normén [MVP]
blog: http://fredrik.nsquared2.com

Jo,

men det var därför jag frågade om det behövdes. Om det inte skiljer på beräkningar etc så finns det ingen anledning att använda arv.

Dessutom finns det andra mönster än arv för att göra beräkningar mm baserat på en typ.