OOP implementatie CMS flexibel houden

[Christiaan]

Ik ben momenteel bezig met het ontwikkelen van een nieuwe generatie van een uitgebreid CMS. Op dit moment beheert een enkele instantie van dit CMS meer dan 100 websites. Deze hebben allen een totaal andere frontend en andere data. Het CMS is qua ontwerp op dit moment ook object georienteerd omdat informatie over diensten (bijvoorbeeld) via een object 'Dienst' wordt toegevoegd, en Nieuws via een object 'Nieuws'. Alle sites putten uit een totale repository van meer dan 70 objecten.

In de huidige situatie is de implementatie weliswaar via .NET en met een assembly voor de code, maar deze code is niet OO zoals het zou moeten. Het nieuwe systeem moet wel netjes OO zijn, waarbij classes de diverse ontwerpobjecten (zoals nieuws, diensten, e.d.) representeren.

De gewenste situatie
De gewenste situatie is dat de object structuur van het CMS zeer flexibel is. Ik wil niet nu al hoeven vast te stellen welke objecten er allemaal zullen gaan zijn en welke velden deze hebben. Mijn wens is om een soort baseobject te definieren die door andere objecten wordt georven. Dit basisobject bevat alle standaardvelden (ID, datum van creatie, wijzigingsdatum, enz) en de onderliggende objecten breiden dit uit met extra velden. Bij een Productobject wordt daar bijvoorbeeld Prijs, Kleur en Vorm aan toegevoegd.

Ik wil niet dat - elke keer als een klant een extra veld wil of er een nieuw object nodig is - de code moet worden aangepast. Bij voorkeur zijn de objecten, en de informatie die per object gedefinieerd kan worden, via het CMS te beheren. Zo kan (in potentie) elk denkbaar object aangemaakt worden, zolang het niet hele vreemde eigenschappen heeft (dat soort objecten hebben we ook, zoals een webshop, maar dat valt even buiten deze discussie).

Het probleem
Ik weet niet goed hoe ik het bovenstaande kan implementeren. Het is voor mij geen probleem om het ontwerp helemaal uit te werken in VB.NET met een assembly met classes. Probleem is dat de structuur dan dus vast staat, en niet gewijzigd kan worden (voor zover ik weet) zonder in de code van de assembly te wroeten. Dat is een probleem op implementatiegebied. Hoe kan ik flexibele objecten maken die - bij wijze van spreke - tijdens runtime kunnen worden gemaakt (de structuur)?

Het tweede probleem is hoe ik dergelijk flexibele data moet persisteren in een database. Ik weet niet van tevoren welke velden en welke objecten er zijn, dus de structuur is grotendeels onbekend. Op zich is dit heel dirty op te lossen met een tabel voor Objecten, eentje voor Velden en eentje voor Waarden, maar een dergelijke abstractie in de database vind ik erg lelijk. Om over performance maar niet te praten. Een betere oplossing lijkt te liggen in XML, bijvoorbeeld door tabellen te maken waar in een laatste kolom XML kan worden geplaatst om een X aantal andere kolommen te definieren. Ik maak gebruik van SQL Server 2005, dus dat kan met XQuery. Een laatste oplossing is dat ik een losse database maak voor objectinformatie (Objecten, Velden, Relaties) en vervolgens via een DBAL alle tabellen dynamisch aan laat maken en laat wijzigen wanneer de objectinformatie wijzigt. Alle objecten die nieuw worden toegevoegd worden dan automatisch als tabel opgesteld.

Hebben jullie suggesties of inzichten in dit ontwerpvraagstuk? Het is echt noodzakelijk om het CMS zo flexibel te maken, aangezien we momenteel veel tijd kwijt zijn met het toevoegen van een veldje hier of een veldje daar aan een object. Dat kost tijd en dus geld. Een goede en flexibele oplossing is ook beter voorbereid op de toekomst.


Een belangrijke voetnoot
Het gaat nadrukkelijk om relatief eenvoudige contentobjecten, zoals nieuws, diensten, producten, auto's, producten, enzovoorts. Ze bestaan vrijwel altijd uit een enkele tabel met een X-aantal velden in de huidige implementatie.

[whoami]

k wil niet dat - elke keer als een klant een extra veld wil of er een nieuw object nodig is - de code moet worden aangepast. Bij voorkeur zijn de objecten, en de informatie die per object gedefinieerd kan worden, via het CMS te beheren. Zo kan (in potentie) elk denkbaar object aangemaakt worden, zolang het niet hele vreemde eigenschappen heeft (dat soort objecten hebben we ook, zoals een webshop, maar dat valt even buiten deze discussie).

Hoe zie je dat dan ? Qua validatie, qua representatie, qua persistence ?

Ik wil niet dat - elke keer als een klant een extra veld wil of er een nieuw object nodig is - de code moet worden aangepast. Bij voorkeur zijn de objecten, en de informatie die per object gedefinieerd kan worden, via het CMS te beheren. Zo kan (in potentie) elk denkbaar object aangemaakt worden, zolang het niet hele vreemde eigenschappen heeft (dat soort objecten hebben we ook, zoals een webshop, maar dat valt even buiten deze discussie).

Je kan iets zo generiek mogelijk gaan maken, maar je kan het ook zodanig generiek maken, dat het uiteindelijk niet meer werkbaar is.

Op zich is dit heel dirty op te lossen met een tabel voor Objecten, eentje voor Velden en eentje voor Waarden, maar een dergelijke abstractie in de database vind ik erg lelijk. Om over performance maar niet te praten.

Er is altijd een afweging die je zal moeten maken ...

Ik persoonlijk vind dat je niet goed bezig bent als je geen 'afgelijnde' definitie-studie hebt van: dat wil ik voorzien, en dat niet. Waarmee ik bedoel: als je zegt 'ik wil alles wat denkbaar is kunnen voorstellen en opslaan en ik wil al die dingen at runtime kunnen definieren', dan denk ik dat je best toch nog eerst maar eens nadenkt over wat je nu echt precies wilt.
Het is onmogelijk om dit te kunnen verwezenlijken EN een mooie DB structuur & een mooi objectmodel te hebben. Als je dit wil, zal je hoedanook met IL emitting moeten werken, me dunkt.

Een betere oplossing lijkt te liggen in XML, bijvoorbeeld door tabellen te maken waar in een laatste kolom XML kan worden geplaatst om een X aantal andere kolommen te definieren. Ik maak gebruik van SQL Server 2005, dus dat kan met XQuery.

En hoe denk je dat de performance hier van zal zijn ?
Stel nu eens dat je alle objecten van type 'X' wilt ophalen die niet voorkomen in de verzameling van objecten van type 'X', waarbij veld 'A' de waarde 1 heeft. Ik zeg maar wat ...

Het is echt noodzakelijk om het CMS zo flexibel te maken, aangezien we momenteel veel tijd kwijt zijn met het toevoegen van een veldje hier of een veldje daar aan een object. Dat kost tijd en dus geld. Een goede en flexibele oplossing is ook beter voorbereid op de toekomst.

Hetgeen jij wilt opzetten, zal ook tijd en geld kosten (in hoeverre het al mogelijk is).
En, dan moet je ook eens nagaan of je systeem ook wel zo onderhoudbaar zal zijn als je nu denkt ...

[Alex]

Wat ik hoor (als medewerker van een CMS Vendor) is dat je een cMS out of the box wilt. Dit gaat 2x duurder en minder onderhoudbaar worden, believe me.

Kijk voor de gein eens naar DotNetNuke / Umbraco. Deze open source CMS-en werken perfect met .NET zijn redelijk tot goed opgezet. En worden breed gesupport.
Commercieel kun je denken aan: MediaSurface / EpiServer / Sitecore(mijn werkgever).
Qua licentie heb je het dan wel gelijk over 50k. Maar dan heb je wel update garanties. En 'proven' systemen.

Tis maar een tip, voordat je 8 maanden gaat bouwen aan aan applicatie waar nooit 'n eind aan gaat komen.

Technisch: Niet genoeg OO vind ik heel raar. Iets is OO of niet. Ik kan me voorstellen dat het niet prachtig is opgezet. En ook termen als 'zou moeten'. Ik vind dit erge box gedachtes. Als je met dat in je hoofd wat nieuws gaat maken moet je zo erg oppassen dat je niet gaat over-engineeren.

[ Voor 0% gewijzigd door Alex op 15-03-2008 11:22 . Reden: Linkfix ]

[Christiaan]

Alex schreef op zaterdag 15 maart 2008 @ 11:21:
Wat ik hoor (als medewerker van een CMS Vendor) is dat je een cMS out of the box wilt. Dit gaat 2x duurder en minder onderhoudbaar worden, believe me.

Thnx voor de tip, maar ik zie weinig toegevoegde waarde van out-of-the-box systemen. Geen van de CMS-en waar ik mee gewerkt heb kunnen zo goed geintegreerd worden met onze andere systemen dan een intern ontwikkeld systeem. De initiele investering is wellicht groter, maar ons huidige CMS heeft ons de afgelopen zeven jaar (in diverse implementaties) meer opgeleverd. We investeren liever in eigen producten dan in die van anderen. Dat is zeker een keuze, maar tot dusver is dat absoluut de voorkeur.

[Christiaan]

whoami schreef op zaterdag 15 maart 2008 @ 11:00:
Ik persoonlijk vind dat je niet goed bezig bent als je geen 'afgelijnde' definitie-studie hebt van: dat wil ik voorzien, en dat niet. Waarmee ik bedoel: als je zegt 'ik wil alles wat denkbaar is kunnen voorstellen en opslaan en ik wil al die dingen at runtime kunnen definieren', dan denk ik dat je best toch nog eerst maar eens nadenkt over wat je nu echt precies wilt.

Maar dat is niet wat ik schrijf, noch wat ik wil. Wat we nu constateren is dat klanten soms net een ander veldje willen hebben bij een object, bijvoorbeeld Nieuws. Dat moet aangepast worden. Gaat op zich binnen 2 uur, maar ik wil zo min mogelijk in de code hoeven vroeten voor dat soort aanpassingen. Hetzelfde is bijvoorbeeld van toepassing op producten. We hebben vijftien klanten die productinformatie uitlezen. Elke klant heeft net andere wensen. Sommigen willen dimensies, anderen willen voltage, grootte, aantal, enzovoorts. Van tevoren kan ik niet inschatten welke velden klanten in de toekomst allemaal gaan willen. Ik wil vooral dat het systeem flexibel genoeg is dat ik dat - bij wijze van spreken - via hetzelfde CMS in kan stellen. Of een soort meta-CMS. Dat lijkt me allerminst onmogelijk en moeilijk onderhoudbaar.

[flowerp]

Christiaan schreef op zondag 16 maart 2008 @ 13:03:
We investeren liever in eigen producten dan in die van anderen. Dat is zeker een keuze, maar tot dusver is dat absoluut de voorkeur.

Een beetje het bekende NIH syndroom (zie: Wikipedia: Not Invented Here).

Op zekere hoogte kan ik er wel in meekomen, maar zodra het om grote erg algemene systemen gaat moet je wel uitkijken dat je er niet te veel in mee gaat. Zo had ik midden jaren '90 een bijbaantje bij een bedrijfje wat zo dacht over een operating systeem. De programmeur die daar zat had ook z'n houding van: "ik ga me daar een beetje MS nog rijker maken of die hippies van Linux supporten. Zo veel werk is een OS nu ook weer niet; beetje memory managen, wat threads schedulen en wat data naar de disk schrijven." Nu weten we natuurlijk allemaal dat zelf je OS onderhouden onbegonnen werk is. De naam van dat bedrijfje waar ik toen werkte en dat eigen OS in het bijzonder kan ik ook nergens meer terug vinden, waarschijnlijk niet voor niets.

Het zelfde geldt voor dingen als b.v. een Database. Beter niet zelf gaan maken, tenzij je er de resources voor hebt, het je primaire product is, en je het competitief in de markt wilt gaan zetten. Als het 'slechts' een ondersteunend product is voor je bestaande dienst verlening, zou ik echt heel erg hard nadenken over zelf maken.

[Christiaan]

flowerp schreef op zondag 16 maart 2008 @ 13:48:
Het zelfde geldt voor dingen als b.v. een Database. Beter niet zelf gaan maken, tenzij je er de resources voor hebt, het je primaire product is, en je het competitief in de markt wilt gaan zetten. Als het 'slechts' een ondersteunend product is voor je bestaande dienst verlening, zou ik echt heel erg hard nadenken over zelf maken.

Natuurlijk moet je dat niet zelf gaan bouwen. Maar het gaat hier om een CMS. Dat is nou ook weer niet zo ontzettend wereldschokkend groot.

[ Voor 21% gewijzigd door Christiaan op 16-03-2008 13:56 ]

[F_J_K]

Withstupids.org.

Is het niet verstandiger om, als je toch aan het bouwen bent, te zorgen dat de systemen waarmee je koppelt fatoenlijke koppelvlakken bieden ipv. dat je blijkbaar (?) hard in die DB's leest/schrijft?

Ik wil vooral dat het systeem flexibel genoeg is dat ik dat - bij wijze van spreken - via hetzelfde CMS in kan stellen. Of een soort meta-CMS. Dat lijkt me allerminst onmogelijk en moeilijk onderhoudbaar.

En dat is precies wat "elk" goed op-de-plank-CMS standaard kan: o.a. het gebruik (en beheer) van contenttypen

---

Edit: al zou een evt. overstap het geld en de tijd (zeker op de korte termijn) ook wel op krijgen

Maar spiek dus bij andere standaardapps.

[ Voor 12% gewijzigd door F_J_K op 16-03-2008 13:55 ]

[Wim Leers]

Drupal + CCK (Content Construction Kit)

[ Voor 2% gewijzigd door Wim Leers op 16-03-2008 13:59 . Reden: typo ]

[Christiaan]

Jongens, kom op. Ik ben benieuwd naar de oplossing voor een architecturaal probleem, en in plaats daarvan worden allerlei bestaande CMS-en aanbevolen en opmerkingen gemaakt over de strategische beslissing om niet een third-party tool te gebruiken.

Ik ben heel nadrukkelijk NIET op zoek naar een off-the-shelf product. We zijn veel meer tijd en geld kwijt om alle huidige sites over te zetten naar een heel ander CMS. Bovendien ligt de basis er allang. Ik wil alleen zoeken naar technische oplossingen om een goede verbeterslag mogelijk te maken in ons eigen systeem. Dat kost misschien een paar maanden, maar we hebben daar het geld en de tijd voor.

Ik zou liever weten wat volgens jullie veelgebruikte patterns zijn voor dit soort problemen dan te discussieren over onze strategische keuze

[ Voor 19% gewijzigd door Christiaan op 16-03-2008 14:04 ]

[Laurens-R]

Ik heb in het verleden een vergelijkbaar project gedaan en wat wij als groep constateerde was dat de problemen de hoeveelheid problemen niet afnam, maar in een andere hoek kwamen te liggen.

De vragen van de gebruiker verschoven van "Kan je dit veldje toevoegen?" naar "Waarom kan ik dit veldje niet toevoegen?". Gevolg: alsnog nieuwe functionaliteit toevoegen.

Daarbij is het testen van zo'n applicatie niet te doen, omdat je nooit weet wat voor "geniale" velden/constructies etc je gebruiker aan het systeem wilt gaan toevoegen/wijzigen.

Maar goed... wat ik duidelijk probeer te maken: de praktische gevolgen zijn het gewoon niet waard. In mijn ogen is een enorm sterk product wat afgestemd is op bepaalde doeleinden veel effectiever dan een ongelofelijke general purpose applicatie.

Wat ik alleen niet helemaal volg is wat je exacte vraag nou is. We geven antwoorden in de trand van "Doe het niet, het levert alleen meer problemen op!" omdat het ook echt zo is! Als een soort van ervaringsdeskundige (niet in de positieve zin) kan ik je echt mededelen dat dit "not the way to go" is.

[ Voor 60% gewijzigd door Laurens-R op 17-03-2008 02:34 ]

[LauPro]

Dit topic vind ik eigenlijk een non-disccusie. TS vraagt eigenlijk hoe hij het beste zijn bedrijfsstrategie kan uitzetten - bij deze mijn inbreng.

Het doel van je 'herimplementatie' (of misschien beter te noemen rewrite) is dat er straks eenvoudig extra velden en/of objecten kunnen worden toegevoegd aan je databestand (repository).

Dit kan in 3 stappen:
• Je definieert eerst een basissysteem (base), dit bestaat in jouw geval uit het CMS en alle generieke obejcten en functies.
• Projecten die slechts toevoegingen van extra velden of objecten vereisen zonder veel business logic zet je dan in een configuratiebestand van je base.
• Projecten die compleet nieuwe functionaliteiten, objecten en/of business logic toevoegen plaats je in een overlay op je base. Elke keer als je base wijzigt zul je dan dus moeten kijken of er niets breekt.

Op die manier heb je zowel flexibiliteit alswel compleet gescheiden systemen met aangepaste implementaties per project.

En over het wel of niet OOP moeten zijn, het klinkt mij in de oren als een paradepaardje zoals je het brengt, het lijkt mij in dit topic van ondergeschikt belang, evenals het platform dat er wordt gebruikt.

[WouZz]

Wat je kan doen is kijken naar het object model van MMBase. De basis is dat je een content cloud van nodes hebt. Nodes hebben een NodeType en kunnen onderling relaties hebben.

De grap is dat de NodeTypes in XML gedefinieerd staan en die kan je zelfs via een editor in je browser aanpassen. In deze XML definieer je dus je velden en de veldtypes (string / int / xml etc). Aan de hand van deze definitie wordt automatisch de juiste tabel aangemaakt.

Vervolgens kun je via de API of de taglib nodelists (van een bepaald type), een specifieke node (aan de hand van het node id) of nodeclusters (nodes met relaties) ophalen.

Hierbij moet vermeld worden dat je dus geen entity classes hebt, maar een generieke class (NodeType in deze).

Zoals al eerder vermeldt doet Drupal iets dergelijks met de Content Construction Kit.

[raptorix]

Christiaan schreef op zondag 16 maart 2008 @ 13:03:
[...]


Thnx voor de tip, maar ik zie weinig toegevoegde waarde van out-of-the-box systemen. Geen van de CMS-en waar ik mee gewerkt heb kunnen zo goed geintegreerd worden met onze andere systemen dan een intern ontwikkeld systeem. De initiele investering is wellicht groter, maar ons huidige CMS heeft ons de afgelopen zeven jaar (in diverse implementaties) meer opgeleverd. We investeren liever in eigen producten dan in die van anderen. Dat is zeker een keuze, maar tot dusver is dat absoluut de voorkeur.

Kijk eens naar Umbraco, voordeel is dat je dat supergoed kunt integreren met bestaande applicaties, daarnaast kan je het ook op een degelijke manier uitbreiden. Wij gebruiken Umbraco bijvoorbeeld in andere applicaties puur om content te beheren.

Wat fijn aan Umbraco is, is dat er 1 XML object is (in memory & FS), vanuit je bestaande applicatie code kan je daar dus perfect de data voor je classes uit halen. Wij hebben dit ook op vrij complexe sites toegepast, en dat werkt erg goed.

[ Voor 12% gewijzigd door raptorix op 17-06-2008 15:04 ]