Modelgedreven ontwikkelstraat in .NET (6): UI Componenten

 
30 november 2008

Nu ik de onderste lagen of componenten van mijn voorbeeldapplicatie heb gedefinieerd en gegenereerd in mijn eerdere posts in deze serie wil ik nu wat aandacht schenken aan veel voorkomende patronen in user interfaces.

In veel applicaties zien we patronen die in meerdere componenten terugkomen. Zo zien we businessobjecten vaak op de een of andere manier terugkomen in de database maar ook is het logisch om bijvoorbeeld employee objecten te kunnen zoeken en invoeren in een user interface. Deze zoek, navigatie en invoer gebeurt vaak in formuliergebaseerde componentjes die eigenlijk over veel applicaties vrij standaard worden geimplementeerd.
Een extreme en wellicht wat oversimplistische en uniforme vorm van deze transformatie is het naked objects pattern (voor de kenners van dit pattern let op er is zojuist een gloednieuwe .NET variant van dit framework uitgekomen, interessant!).

Wat ik aan de UI kant wil proberen te bereiken is het genereren van een gereedschapskist met onderdelen. Deze onderdelen kunnen vervolgens gebruikt worden als basis voor een te bouwen user interface. Uitbreidingen en maatwerk zijn mogelijk – met hergeneratie – door een passende inheritance strategie te volgen, dit zal ik aangeven in de volgende concrete voorbeelden.
Welke onderdelen zien we in veel applicaties terugkomen? Een eerste lijstje van deze onderdelen volgt hieronder. Per onderdeel zal ik een uitwerking maken in de volgende posts in deze serie.

Grid/browser
Ik heb al een aantal keren applicaties mogen ontwikkelen en dit is in mijn optiek een standaard onderdeel dat ik zou willen hebben voor elk businessobject in mijn model. Een grid waarmee ik door de objecten kan navigeren en dat me op de een of andere manier filtermogelijkheden danwel zoekfunctionaliteiten biedt.
Kersen op de taart zijn de virtual mode in grids (alleen ophalen wat getoond wordt) en sorteren.

Single edit
Voor het bewerken van enkele objecten is het handig een component te hebben dat voor alle velden in het object een invoercomponentje bevat. Features als data binding via een nette MVC implementatie en inputvalidatie zouden hierin meteen meegenomen kunnen worden.

Use Case
In een simplistische wereld kunnen we elke use case die we onderkennen vrij letterlijk terugvinden in een user interface component. Hier zal waarschijnlijk veel handwerk nodig zijn in de UI maar het is wellicht mogelijk om voor use cases eigen componenten te genereren. Hier zal ik op een trial-and-error manier op terugkomen :).

Meer ideeën? Ik hoor ze uiteraard graag.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Architectuur, Development, .Net

Tags: , ,