ORMapping relaties

[Scare360]

Een BatchProcess heeft als intake 1 of meerdere batches en produceerd één batch… die batch kan weer samen met andere batches in een nieuw batchprocess.

Zodra ik een batch uit m’n database en daar een object van maak, wordt tevens een BatchProcess object voor aangemaakt (relatie aanmaken), maar dat BatchProcess object probeert de “aanroepende batch” aan te maken… het BatchProcess maakt ook een output batch aan die weer een proces… een enorme ketting met:

Batch -> proces: 0:n (is gebruikt in)
Batch -> proces: 1:1 (is geproduceerd door)
Proces -> batch 1:n (heeft gebruikt)
Proces -> batch 1:1 (heft geproduceerd)

Relaties. Iemand een suggestie hoe dit op te lossen? Ik heb zelf wel wat ideetjes, maar wellicht zoek ik het in de verkeerde hoek. Al bladerende in Fowler’s boek lijkt me een Value Holder (Value Object) pattern wel aardig. Zoiets als laadt een batch, value holders voor UsedInProcess en ProducedByProcess. Op de eerste methode aanroep een batchproces aanmaken met een value holder voor UsedBatches en ProducedBatch.

Van de andere kant… de ketting moet ik toch “een keer inladen”, dus waarom de implementatie vermoeilijken met een soort van lazy load.

Bedankt voor de reacties iig.

[SWfreak]

Dit is misschien een vieze oplossing, maar hij werkt wel:

code:

BatchProcess                   RelatieTable           Batch
ID                              IDBatchProcess          ID
                               IDBatch

Die aantallen kun je dan met een query opvragen.

[ Voor 7% gewijzigd door SWfreak op 17-03-2003 10:16 . Reden: Layout ]

[EfBe]

Mag ik zeggen dat ik er geen hout van begrijp? Dat plaatje helpt ook niet echt, de omschrijvingen staan verkeerd imho: batchprocess maakt toch de batch aan, het plaatje suggereert het omgekeerde.

[Scare360]

Een ouder kind relatie in die zin dat: ouder 0..* kinderen, kind kan later ook weer 0..* kinderen krijgen etc.

Als je een kind object creert moet een ouder al bestaan, maar zodra je dan een ouder object maakt wil deze ook het kind aanmaken wat in eerste instantie de creatie van de ouder in gang heeft gezet... een mooi cycle heb je dan dus...

Ik heb het nu opgelost met een lazy load. 1 van de twee business objecten wordt lazy gecreerd (ouder=null), zodra iemand kind.ouder property aanspreekt wordt alsnog de ouder gecreerd... het kind bestaat dan al.

Een IExpander interface gedefinieerd met een IsExpanded, Expand... code in een proto type (employees, departments uit de llblgen demo). Jaja klein frameworkje voor de LLBLGen geschreven.

code:

// Methode voor vinden van...
public Employee Find(int id)
{           
    if (_persistReg.EmployeeIdentityMap.ContainsEmployee(id))
    {
        return _persistReg.EmployeeIdentityMap.GetEmployee(id);
    }
    else
    {
        EmployeesGateway empsGateway = new EmployeesGateway();              
        empsGateway.EmployeeID = id;
        empsGateway.SelectOne();
        
        Employee employee = new Employee(
            (int)empsGateway.EmployeeID,
            empsGateway.FirstName.ToString(),
            empsGateway.LastName.ToString(),
            empsGateway.Initials.ToString(),
            empsGateway.Description.ToString(),
            (DateTime)empsGateway.StartedOn,
            (int)empsGateway.SecurityID,
            null);

        _persistReg.EmployeeIdentityMap.AddEmployee(employee.ID, employee);
        return employee;
    }
}

// Uitklappen van het object...zeg maar
public override void Expand()
{
    if (_department == null)
    {
        _department = new DepartmentMapper().FindByEmployeeId(_id);
        IsExpanded = true;
    }
}

Voordeel is dat je een soort van Value Holder pattern implementeerd zonder properties van het type ValueHolder moet gebruiken. Leuke is dat de DataMappers & Lazy Domain objecten verantwoordelijk zijn voor het lazy loading gedrag, en je dus verschillende manieren van lazy load kan implementeren. Ik zal dat met wat sealed classes gaan proberen in de mapper en naargelang het algoritme de juiste load strategie gebruiken.