MMBase is een tool/framework om een CMS mee op te zetten, Hibernate is een ORM-tool (Object Relational Mapping) en zet dus java-objecten om in entiteiten voor een relationele database en vice versa. Deze producten met elkaar vergelijken lijkt op het eerste gezicht wel heel erg op het vergelijken van appels en peren. Eén onderdeel hebben beiden wel gemeen: persisteren van java-objecten. In MMBase zijn dit nodes en in Hibernate POJO’s. MMBase biedt veel meer functionaliteit zoals editwizards, security, een stagingomgeving met een publicatiemechanisme en dan is er nog de CMS container die nog veel meer biedt. Deze functionaliteit laat ik in dit stuk buiten beschouwing, ik richt me alleen op persistentie.

Datamodel
In MMBase ontwerpt de ontwikkelaar het objectmodel en heeft niet direct invloed op het datamodel. Dit wordt gegenereerd door MMBase. De ontwikkelaar legt in XML vast welke objecten er zijn (nodes), welke velden ze bevatten (fields) en welke relatie ze hebben met elkaar. In de configuratie worden gegevens over de database vastgelegd en MMBase zorgt ervoor dat tabellen, constraints en indexes worden aangemaakt in de database. Behalve relationele databases ondersteun MMBase ook objectgeoriënteerde databases. Dit heeft gevolgen voor het datamodel.

Objectgeoriënteerde databases bestaan uit zelf gedefinieerde objecten die van elkaar kunnen overerven (net als java objecten). Relationele databases kennen alleen voorgedefinieerde types waarmee je entiteiten kunt maken, maar die kunnen niet van elkaar overerven. Om deze overerving toch voor elkaar te kunnen krijgen in een relationele database slaat MMBase de gehele hiërarchie van een object op in verschillende tabellen.
Voorbeeld: een artikel erft over van een contentelement. Als MMBase een artikel opslaat, worden er 3 entiteiten vastgelegd; een artikel, een contentelement en een object. Object bevat alleen id, type en eigenaar. Deze eigenschappen worden ook vastgelegd in contentelement en artikel. Er wordt dus 3x dezelfde data opgeslagen. In de praktijk is dit wel iets waar je rekening mee moet houden, want als een contentelement een grote blob bevat wordt deze dus nogmaals in een artikel opgeslagen. Als er beperkt gebruik wordt gemaakt van overerving levert deze redundante data in de praktijk geen problemen op.

Constraints zijn een middel in relationele databases om de integriteit van een relationele database te garanderen. MMBase genereert wel enkele constraints, maar de belangrijkste, de primairy en foreign key constraints, worden niet toegepast. Dit heeft wel consequenties voor performance, maar problemen met data integriteit komen in de praktijk niet voor.Het door MMBase gegenereerde datamodel is geen model dat een ontwikkelaar zelf zou ontwerpen, maar in de praktijk voldoet het.

Hibernate gaat uit van een bestaand of zelf te ontwerpen datamodel. Hierbij is de ontwikkelaar zelf dus verantwoordelijk voor het toepassen van constraints en indexes. Dit komt de data integriteit en de performance zeker ten goede. Een nadeel hiervan is dat dit wel extra werk is voor de ontwikkelaar. Het datamodel komt er niet vanzelf zoals bij MMBase, maar moet zelf ontworpen worden. Hibernate heeft een tool set die de ontwikkelaar hierbij ondersteunt.

Het aanpassen van het datamodel kan ook lastiger zijn dan bij MMBase, vooral als dit een aanpassing is van een primairy key of een relatie. De identifier van een entiteit is in MMBase altijd een gegenereerde code. In Hibernate kan dit een natuurlijke sleutel zijn (evt. bestaand uit meerdere velden). Zo kan voor een persoon de naam en de geboortedatum als primaire sleutel worden aangemerkt. Als dan besloten wordt dat de naam wordt opgesplitst in voornaam, tussenvoegels en achternaam betekent dit dat er veel aanpassingen moeten worden gedaan in de applicatie. In MMBase is zo’n aanpassing vrij eenvoudig. Ook het toevoegen van eigenschappen aan een relatie kan lastig zijn in Hibernate. In MMBase wordt een relatie altijd opgeslagen als losse entiteit, in Hibernate modelleert een ontwikkelaar over het algemeen alleen een tussentabel als het een veel-op-veel relatie betreft.

Caching
MMBase heeft een eigen caching mechanisme dat een wezenlijk onderdeel MMBase is. De matige performance die veroorzaakt wordt door het datamodel wordt hiermee ondervangen. Via de admin tool van MMBase is deze cache runtime te configureren.

Hibernate heeft geen eigen caching mechanisme, maar biedt de mogelijkheid een third party caching tool (zoals EHCache) in te pluggen. Zo’n caching tool richt zich uitsluitend op caching en is daar over het algemeen dus beter in. De caching van MMBase voldoet echter goed en vooral de runtime configuratie mogelijkheid is een mooie feature.

Backward compatibility
Backward compatibility staat hoog in het vaandel bij MMBase, zodat upgraden niet onevenredig veel inspanning kost. Alhoewel dit een goed uitgangspunt is, worden hierdoor de mogelijkheden voor doorontwikkeling van MMBase erg ingeperkt. Het datamodel zou nooit kunnen veranderen, want dat breekt backward compatibility. Ook zullen objectgeoriënteerde databases altijd ondersteund moeten blijven terwijl deze in de praktijk zeer weinig voorkomen.

Conclusie
Uit het bovenstaande zou je misschien de conclusie trekken dat MMBase een matig product is. Dit is een vertekend beeld omdat dit artikel uitsluitend gericht is op persistentie. MMBase blinkt naar mijn mening niet uit op dat gebied, maar een content management systeem is veel meer dan alleen persistentie.

Hibernate richt zich wel uitsluitend op persistentie en is daar naar mijn mening beter in dan MMBase. Hibernate biedt daarentegen niets extra om een CMS mee te bouwen.

Voor het bouwen van een CMS is MMBase een goede basis. Voor toekomstige versies zou MMBase wel een voorbeeld kunnen nemen aan Hibernate. Daarin is bijvoorbeeld caching en connection pooling plugbaar. Zo zou ook persistentie in MMBase plugbaar kunnen worden. Hierdoor gaat daar geen ontwikkelcapaciteit in zitten en kan men zich uitsluitend op CMS functionaliteit richten. Het is de vraag of dit wel mogelijk is met behoud van backward compatibility.