Verpakking

Dit is net het herophalen van data waarvan we al zeker zijn dat bestaat. We hebben in een vorige stap die data opgezocht. Nu willen we die nog eens gaan uitlezen uit de DB.

Nee, het is best van deze data op te kuisen. Kan in het slechtste geval nog vervuild zijn van de vorige iteraties over de bonnummers

OrderAPI newen in constructor graag.

Ook hier gebeurt wel heel erg veel op 1 lijn hé...
Tenminste het product verdient wel een eigen lijn vind ik en dan nog liefst met een ProductRolAPI die in de constructor genewed wordt (en tevens niet van de DomeinContext afgenomen wordt )

Typo

Deze houdt toch risico in, denk ik, want je geeft normaal een object terug van type DS.Prod.OptiBox.BoxDataMetID, maar de logica laat toe dat dit object undefined is en op de volgende lijn van het stuk code dat deze private method gebruikt wordt er gebruik gemaakt van een property van dit object. Je komt ermee weg omdat de repo daar met lege strings overweg kan, maar 't is niet helemaal correct zoals het hier afgehandeld wordt. Minimaal zou je een leeg object moeten teruggeven, of je moet er nog een "Bestaat..." of "Heeft..." tussen moeten steken.

Hier gebeurt wel heel erg veel op 1 lijn hé
Tenminste het product verdient wel een eigen lijn vind ik en dan nog liefst met een ProductRolAPI die in de constructor genewed wordt (en tevens niet van de DomeinContext afgenomen wordt )

Is het niet gevaarlijk die al uit de repo te gaan verwijderen terwijl er nog processen (de calls hieronder) in gang gaan gezet worden, die misschien nog gaan crashen? Moet deze verwijder niet op het einde van deze method uitgevoerd worden (vlak voor het loggen dat hij ermee klaar is)?

Aangezien ge hier beide mogelijkheden voorziet (injecteren of de echte gebruiken) moet ge dat ook bij de parameter duidelijk maken door die als lege string te defaulten, zoals bij de andere parameters gedaan is. Op die manier, als iemand deze klasse instantieert ergens, ziet die persoon gelijk aan de parameterdefinitie dat die niet per se moet meegegeven worden (en dat dan een nieuwe instantie voorzien is door deze constructor).

Graag de èchte instantiëren en niet van de DomeinContext afnemen.

Moet/mag deze lijn in comment blijven staan? Graag comment erachter met meer duiding.

Best diene Partialloadonfloor hier ook nog eens defaulten op 0, want hij wordt in deze method rechtstreeks gebruikt enerzijds en anderzijds wordt hij als parameter in de aanroepende method toch ook al gedefaulted op 0, dus mag consistent zijn, zoals gedaan is bij MinFillPercentage. Kan anders gevaar opleveren als deze private method ooit nog door een andere method gecalled wordt ook, waarin dan deze parameter nergens gedefaulted staat. (= undefined at runtime)

Korttekst = string (gotta love Cache en types )

Moet deze in comment blijven staan? Mag die niet gewoon weg dan? Minstens een comment erachter zetten over het waarom de lijn in comment staat

Lekker muggeziften... dimmekes altijd bovenaan in de method zetten, vóór de setjes.

Graag de èchte instantiëren en niet van de DomeinContext afnemen.

Die Dummy ook buiten de While loop dimmen graag

Indien er eerst een true is en dan false, zal deze false-negative zijn, nee?

Deze property wordt nergens gebruikt, kan weg volgens mij

Misschien hier een loglijntje of iets dergelijks aangezien deze error anders gewoon wordt 'opgegeten'?

De optimizer gaat data zoeken met dikte 3 voor kraft klein en 4.2 voor bv halux. Nadat data gevonden is moeten we er een geheel getal van maken, anders kan het Kraftmachine dit niet interpreteren. Er is dus een verschil tussen voor en na de optimalisatie