Design patterns

From WOSI
Jump to: navigation, search

Dit is een (klein) voorbeeld van enkele design patterns die je in WOSI applicaties terug kunt vinden. Er zijn een hoop anderen, dit verschilt natuurlijk per project.

Builder

Dit patroon wordt onder andere gebruikt om complexe datamodellen stap voor stap op te stellen. Een voorbeeld is het communicatie-object binnen OGDB en SCAGO. Hiervoor zijn verschillende parameters nodig, zoals ontvangers (personen in de database, maar ook losse e-mails), bericht-templates, bericht-variabelen, en de manier hoe de communicatie verzonden moet worden. Via de communicatie-builder worden de parameters eerst vastgelegd, pas op de laatste stap worden de communicatie- en bericht object-hiërarchieën (correct) aangemaakt. Dit maakt het proces foutbestendig en eenvoudiger.

Composite

Bij het gebruiken van jQuery (Javascript) komt iedereen hier in aanraking mee. Met het composite design patterns worden collecties van elementen en enkele elementen op dezelfde manier behandeld. Operaties op het HTML Document Object Model via jQuery worden via “selectors” gedaan, en deze kunnen verwijzen naar enkele of meerdere elementen.

DTO

DTO’s worden veel gebruikt voor “tussenobjecten” en communicatie tussen externe systemen/API’s. Bijvoorbeeld om van een “zwaar” model (bv. Artikel met HTML, attachments) een eenvoudige representatie te maken voor zoekresultaten (alleen naam, intro tekst). Ook is het nuttig om consumers van een eigen REST API een DTO te laten gebruiken, zodat wijzigingen op het “native” objectmodel van de applicatie geen incompatibiliteiten veroorzaken.

Fluent interface

QueryDSL, een DSL (domain-specific language) library gebruikt door vrijwel alle WOSI projecten voor het bouwen van database queries. Dit is een goed voorbeeld van het fluent interface design pattern. Door het “chainen” van bepaalde methoden en “path objects” kunnen op deze manier type-safe en injection-safe queries gemaakt worden. Er kunnen ook extensies gemaakt worden (en dat doen we ook) om veelgebruikte stukken SQL te hergebruiken.

Proxies en Lazy initialization

Bij het gebruik van Hibernate/JPA is het belangrijk om deze twee concepten goed te begrijpen. Op het moment dat een gemapped database entity (bv. Gebouw) met behulp van hibernate wordt opgehaald, krijg je niet het concreet type van het object terug, maar een proxy. Het is meestal veel te zwaar om alle informatie van een entity en haar relaties in één keer op te halen, en meestal ook onmogelijk door bidirectionele of cyclische relaties. Daarom haalt hibernate relaties (bv. bewoners van het Gebouw, of het onderhoudsplan van het Gebouw) pas op wanneer je het opvraagt (lazy initialization). Dit gebeurt door een proxy te maken van het entity object (Gebouw), en de getters te vervangen door code die een database query uitvoeren voor de informatie die je op dat moment nodig hebt.

MVC

Dit vormt de basis van het Spring MVC framework, en wordt uiteraard grootschalig toegepast. Hiermee wordt view-logica en business-logica via een vaste structuur gescheiden, wat belangrijk is om grote applicaties goed mogelijk te kunnen uitbreiden en onderhouden.

Service layer

Naast de domain models en controllers gebruiken we in WOSI projecten een apart service layer. Dit zijn klassen waarin we queries, acties of berekeningen op een bepaald entiteit of aspect van het systeem uitvoeren. De services worden door middel van dependency injection gebruikt door controllers, maar ook onderling. Dit zorgt voor een betere scheiding tussen het domein model en business logica.