Soort van eigen MVC maar stuit op issues

[Verwijderd]

Ik heb een soort van eigen interpretatie van het MVC pattern in een .NET project en zal even kort uit proberen te leggen waarom zo.

Een aantal van mijn objecten zijn ondergebracht in classes en binnen die classes zat businesslogic incluis datareadertjes etc. Zat ondertussen ook wat met WCF te spelen en kwam erachter dat dat soort objecten niet zomaar gemakkelijk geserialized kunnen worden dus besloot mijn ontwerp iets aan te passen, just in case...

Nu zijn er nog steeds die classes met logic erin, maar ook heb ik een model van de properties van bepaalde objecten en als ik iets aan bijv een grid hang, dan is het een 'list of t' van dat model.
Hier komt het probleem: Die list of model moet gevuld worden en als ik bijv eerst een datatable als itemsource van een grid instelde ging het nagenoeg instant, zelfs met een miljoen records.
Nu heb ik een model en mijn resultset van de database moet eerst in een list of bla gepropt worden. Die loop duurt in een geval van meer dan 100.000 records al best aardig lang. Daar komt bij dat dbnull velden gechecked moeten worden omdat die niet zomaar in een nullable of t gepropt mogen worden, dus per property een extra check en eventuele conversieslag.

Anyway, ik heb het idee dat ik het niet juist aanpak.
Volledig overleveren aan zoiets als het entity framework is geen optie omdat ik ook te maken heb met een backend die zich daar niet voor leent.

[dingstje]

Je kan je in zo'n gevallen ook eens de vraag stellen of het wel nodig is dat je werkelijk 100.000 records inlaadt en in een grid propt. Tenzij je heel specifieke requirements hebt, gaat toch niemand een grid van 100.000 records manueel doorploegen op zoek naar het juiste lijntje? Werk je dan niet beter met een goede zoekmogelijkheid om snel bij een subset van potentieel relevante records te komen?

Om op je eigenlijke performancevraag terug te komen: ik weet niet wat je begrijpt onder 'aardig lang', maar in elk geval moet je bij performance-issues gewoon een profiler nemen en kijken welk deel van je code de meeste tijd in beslag neemt, en kijken of je daar wat aan kan doen. Zolang je dat niet weet, schiet je maar wat in het wild met performanceoptimalisaties en zal je wellicht een aantal micro-optimalisaties doorvoeren die maar weinig zoden aan de dijk brengen...