[C#] Implementatie theorien (zoals mvc)

[BlackHawkDesign]

Beste Tweakers,

Ik zit eigenlijk een beetje met een designpuntje. Momenteel heb ik net me Informatica opleiding achter de rug en ben ik bezig met een Master. Ik werk ook bij een softwarebedrijfje en eigenlijk ben ik nu een beetje op een punt gekomen dat ik de theorie van afgelopen 4 jaar en komende jaren wil gaan inzetten.

Ik zit dus vaak met zaken waar ik niet goed een beslissing kan over nemen en daarom vraag ik jullie om advies.Om het goed concreet te maken: Ik ben bezig met een c# applicatie voor mezelf waarmee ik straks wil gaan budgetteren. Nou heb ik het als volgt ontworpen:
1) DataAccess layer : Deze voert de stored procedures uit en geeft een dataset / datatable terug
2) Model layer: Deze bestaat uit objecten zoals category, transaction e.d De data access layer zet de datatables om in deze objecten
3) Guicontroller : deze handelt de acties van het formulier af
4) Gui, de windows forms
5) Andere modules, maar die zijn in dit topic niet zo van belang

Nu zit ik eigenlijk een beetje met 2 dingen :
1) De model layer werkt niet echt relaxt, controls zoals een gridview, combobox werken heel relaxt met een datatable. Echter maak ik al een extra stap in de data access layer om die data table om te zetten naar een model object, maar in de gui kan ik weer omzetten met een loopje. Terwijl ik een datatable direct aan het control hang.

2) De gui controller handelt de acties af, echter moet het uitlezen van de velden e.d gebeuren in de gui en het verwerken van de gegevens in de data access layer. De controller begint meer te lijken als een soort wrapper klasse van de data access layer. Bovendien begint er steeds meer code in de gui te komen.

Bij punt 1 ben ik geneigd om de model layer er gewoon uit te slopen. Echter weet ik vanuit de theorie dat het juist heel slim is om die er in te houden. Voor me gevoel zet ik de model laag niet goed in, of is de overhead ondergeschikt aan het feit dat het heel relaxt is om met de business objecten te werken? (de model objecten dus)

Bij punt 2 wil ik wel graag meer code in de controller klasse stoppen, echter dan wordt de binding tussen de 2 weer te groot. De validatie e.d gebeurd al wel in de controllerklasse, wat naar mijn idee goed is, echter vraag ik me af of ik nog meer moet doen.

Ik beschik dus wel over de theorie, alleen het toepassen hiervan gaat nog niet helemaal zoals ik het wil. Hopelijk kan een van jullie me weer even op het rechte pad zetten!

[RobIII]

"Implementatie theorien" >> Design patterns. Zoekt handiger, vind meer

[ Voor 35% gewijzigd door RobIII op 25-01-2010 12:35 ]

[BlackHawkDesign]

Ja maar dan eigenlijk meer in het feit van HOE te implementeren, met design patterns ben ik uiteraard bekend

[jmzeeman]

In de praktijk wordt vooral in de wat kleinere projecten inderdaad vaak de model laag weg gelaten en worden de .NET data classes als model gezien. Of dit wenselijk is ligt natuurlijk aan een heleboel factoren, vooral als de database leidend is en het dus vooral een data entry applicatie is en de DB over goede SP's beschikt hoeft dit niet zo'n punt te zijn.

Als je wel graag je model laag wil houden zijn er daar ook mogelijkheden voor. Zo heb je bijvoorbeeld de ObjectDataSource waarin je je model objecten kan stoppen en aan kan geven hoe die deze moet benaderen. Deze werkt als een vertalingslaag tussen je model en de databinding controls.
Ook is het mogelijk om in je model .NET interfaces te implementern zoals bijvoorbeeld IList, IListSoure of IDataSource. Nadeel hiervan is dat deze niet altijd met alle bindings werken en je dus het risico loopt dat je model teveel aan je gui gaat koppelen.

[BlackHawkDesign]

Daar kan ik wat mee Het is maar een kleine app. Ik heb besloten de model laag er uit te gooien.

Had je nog advies voor punt 2?

[ Voor 3% gewijzigd door BlackHawkDesign op 28-01-2010 12:03 ]

[Peregrine]

MVC is een leuk 'pattern' (ik ben van mening dat het net geen pattern is, maar da's filosofisch) maar is net als alle patterns niet altijd even goed toepasbaar.

Wat ik lees uit je verhaal is dat je functionaliteit van je app overeenkomt met het (direct) bewerken van de inhoud van je database, punt. Geen extra functionaliteit of complexe logica. In dat geval is een MVC wat mij betreft overbodig / onhandig / niet toepasbaar. ik denk dat je je kunt beperken tot een enkele schil over de database, wat inderdaad neerkomt op kleine logica in de GUI. In de praktijk zal je toch zien dat de View en Control vaak zoveel raakvlakken hebben dat ze eigenlijk een zijn.

Mocht de logica wat complexer worden, dan kan je er een laag tussen hangen om dit te scheiden. Dit kan ook afhangen wat de "niet zo van belang" zijnde andere modules gaan doen.