Generic CRUD component

Belangrijkste  voordeel van een ORM framewok, is het voorkomen van telkens opnieuw code maken om data uit een database te transleren naar een object-type. De belangrijkste opereraties die met zo’n object moeten gebeuren zijn: aanmaken (Create), opvragen (Read), bijwerken (Update) en verwijderen (Delete), ofwel CRUD. Je zou die functies voor ieder type apart kunnen maken, maar via de standaarden JPA en Java 1.5 is het ook goed mogelijk een generiek CRUD-component te maken in Java. Via deze service zijn alle CRUD-operaties beschikbaar voor persistent Java-objecten. Op die manier kun je heel snel b.v. een GebruikersService, AdresService.
Ik was niet de enige met dat idee, na wat snel zoeken vond ik het volgende artikel van Adam Bien: Generic CRUD Components with Java EE 5.  Na een discussie met een collega kwamen we erop dat Generic CRUD component zeer veel weg heeft van het Active Record Pattern van Martin Fowler.
Het Active Record Pattern is uiteraard uitgewerkt in Ruby on Rails. In Java is er sinds kort ook een implementatie, Active Objects. Active Objects wordt uitgelegd in een artikel van Daniel Spiewak op Javalobby.org.
In zekere zin lijkt ActiveRecord erg op een DAO-pattern. ActiveRecord werkt echter goed in dynamische talen als Ruby en Groovy, DAO is beter geschikt voor niet dynamische, static-type talen als Java. Wat ik dus zoek is niet een Generic Crud Service, maar een Generic Dao, gelukkig al beschreven door IBM.
Een afgeronde implementatie van een Generic DAO kon ik helaas nog niet vinden, maar in combinatie met Spring zou zo’n implementatie toch weinig code bevatten. Een goede omschrijving is ondermeer DRY CRUD DAOs with JPA. Op Google Code vond ik het Crank project, die een implementatie van een uitgebreide Generic Dao levert.

Er is niets nieuws onder de zon, zolang je maar de juiste (en dezelfde) woorden gebruikt en kent!

The new stuff (RIA)

Sinds zeer recent ben ik begonnen aan een nieuw project. Het project is nog heel vers, maar aangezien ontwikkelingen snel gaan wil ik toch al over wat technische overwegingen schrijven.
Als frontend hebben we na korte overweging voor Adobe Flex gekozen. Ik was nooit erg enthousiast over de HTML/Javascript combinatie, dus eerste keus is een RIA-framework (over GUI, zoals dat vroeger heette) dat ook echt bedoeld is voor RIA. In tegenstelling tot de 13-dozijn DHTML/Ajax/XHTML frameworks is de keuze dan gelukkig wat overzichtelijker. Gezien voorgaande ervaring hebben we voor Flex gekozen boven JavaFX. W

Heel toevallig, las ik nu een artikel van een oud-collega, over Spring Security in combinatie met Flex. RIA-applicaties zijn wat veiligheid betreft risicovoller: op de client is dikker (qua software en logica) dan bij tradionele HTML-interfaces. Wanneer geen rekening mee gehouden wordt, is er grotere kans dat de server onbeschermd ontbloot is.
In het artikel wordt uitgegaan van de combinatie Flex/Spring/BladeDS als basis voor de architectuur van de applicatie. BladeDS is een remoting-framework, waarmee de Flex-client-applicatie, op de computer van de gebruiker communiceert met de applicatie op de server. Spring-security is een wordt als een filter-class op de server-side toegevoegd. Samen met wat client-side code in flex, zorgt het geheel ervoor dat de gebruiker een nette login-box krijgt, wanneer hij de applicatie wilt gebruiken. Lees de details in: Integrating Flex, BlazeDS, and Spring security op de Adobe Developer Center.