[java/web] framework voor CRUD operations

[Verwijderd]

Het schrijven van CRUD (Create, Read, Update, Delete) operations in een (JSP/Struts) webapplicatie is vaak een tijdrovende en omslachtige operatie.
Daarnaast is de code voor verschillende 'entities' vrijwel gelijk. Of het nu gaat om CMP entity beans, Hibernate POJO's of SQL Resultsets de code voor het presenteren van een lijst met een edit en delete knopje is min of meer gelijk.

Daarom ben ik op zoek naar een open-source framework die het schrijven van CRUD operations kan vereenvoudigen.

Hetgeen ik zelf al heb gevonden is het volgende:

- Oracle ADF (Erg goed, echter wel closed source).
- Display Tag Library (Erg goede library, maar alleen voor het presenteren van tabellen, niet voor het creeeren/deleten/updaten van entities)
- DBForms (Doet precies wat ik wil, echter werkt het alleen met plain SQL en ik wil graag kunnen werken met Hibernate, CMP, Cayenne, TopLink, etc....)


Zijn er bij jullie (open-source) frameworks bekend die het creeeren van deze basis taken kunnen vereenvoudigen?

[Verwijderd]

Bedoel je dit met betrekking op de presentatielaag of de bedrijflogica-laag? Ik zie trouwens niet waarom dit met jsp/struts ism taglibs omslachtig zou zijn? m.b.t. sql operaties gebruik ik een zgn persistent object waar je in feite alleen maar een sql string hoeft aan te bieden vanuit een willekeurige klasse. Deze code schrijf je maar 1 keer. Verder is het struts framework voor een groot deel gebouwd op interfaces, juist om omslachtig programmeren te voorkomen... Voor de presentatie gebruik ik meestal taglibs, een soort xml notaties voor de uitvoer, wederom kun je hier heel dynamisch mee programmeren, zodat je dus je code 1 keer schrijft en vervolgens altijd gebruikt.

Of snap ik je vraag niet?

[Verwijderd]

Verwijderd schreef op 16 augustus 2004 @ 15:28:
Bedoel je dit met betrekking op de presentatielaag of de bedrijflogica-laag? Ik zie trouwens niet waarom dit met jsp/struts ism taglibs omslachtig zou zijn? m.b.t. sql operaties gebruik ik een zgn persistent object waar je in feite alleen maar een sql string hoeft aan te bieden vanuit een willekeurige klasse. Deze code schrijf je maar 1 keer. Verder is het struts framework voor een groot deel gebouwd op interfaces, juist om omslachtig programmeren te voorkomen... Voor de presentatie gebruik ik meestal taglibs, een soort xml notaties voor de uitvoer, wederom kun je hier heel dynamisch mee programmeren, zodat je dus je code 1 keer schrijft en vervolgens altijd gebruikt.

Of snap ik je vraag niet?

Misschien begrijp je de vraag niet helemaal. Inderdaad je kunt met JSP / Taglibs zondermeer een heel eind komen. Stel dat ik een applicatie heb met daarin 3 entities. Dan moet ik 3 jsp pagina's coderen met daarin een tabel om weer te geven wat er in mijn tabellen zit. Daarnaast moet ik voor elke entity een update (jsp)pagina bouwen, misschien kan ik voor de create de update pagina hergebruiken en de delete actie opnemen in het overzicht.

Dan moet ik een (struts) actie implementeren voor elke CRUD actie per entity. In totaal dus al 6 files per entity. Dus 3 x 6 = 18 files voor 3 entities.

Stel nu eens dat ik 300 entities heb..... Get the point?

Ik wil graag een framework wat (misschien op basis van reflectie) mijn entities bekijkt, vervolgens JSP overzicht / update / create pagina's met bijbehorende (struts)actions kan genereren zonder dat ik dat allemaal met de hand hoef te coderen. Misschien hoeft hoeft het overigens niet gegenereerd te worden maar kan er run-time iets slims bedacht worden. (Kijk maar eens naar Oracle ADF).

Eigenlijk wil ik dus alleen mijn entity programmeren (CMP / Hibernate / SQL).

Vervolgens zou ik misschien een taglib willen hebben waar het volgende mee kan:

code:

<bla:list createButton="true" deleteButton="true" updateButton="true"  "pageSize="10"/>

Dit zou een form moeten generen met daarin een tabel met de inhoud van mijn database tabellen, inclusief update knop, create knop, delete knop... etc...

[zneek]

hier heb ik ook wel eens over na zitten denken. Lijkt een mooi idee, maar je loopt al snel tegen allerlei hobbels op. Bijv. je wilt niet al je velden uit je entity bean op een form hebben. Er kunnen eigenschappen zijn die niet voor iedereen van belang zijn. Daarnaast, hoe zou dat framwork moeten bepalen hoe hij de informatie moet tonen? De ene keer wil je een invulvak van 6 chars hebben (postcode veld bijvoorbeeld) andere keer 1 van 50 chars (achternaam).

Een oplossing zou natuurlijk zijn om al je veldtypen uit te modelleren zodat het framework aan het type ziet wat voor input veld er gegenereerd moet worden. Je entities krijgen dan geen String voornaam maar String50 voornaam bijv.

Overigens heb ik bij de manier waarop ik nu werk ook redelijk weinig overhead code. commons beanutils is je vriend voor het zetten van veel gevarieerde properties. Een goede DAO opzet is ook erg handig.

[-FoX-]

Hmm, ik kan je niet direct een framework opnoemen die iets dergelijks genereert.

Maar langs de andere kant begrijp ik je frustratie ook niet echt. Wat jij wil kan je toch perfect met bijvoorbeeld Struts/Hibernate realiseren. Neem daar dan nog een layout library bij zoals Struts Layout en je bent toch vertrokken, niet?

Overigens kan je voor Create/Update perfect hetzelfde formulier gebruiken en via Hibernate doe je dan gewoon een SaveOrUpdate();

[Alarmnummer]

-FoX- schreef op 16 augustus 2004 @ 17:05:
Hmm, ik kan je niet direct een framework opnoemen die iets dergelijks genereert.

Maar langs de andere kant begrijp ik je frustratie ook niet echt. Wat jij wil kan je toch perfect met bijvoorbeeld Struts/Hibernate realiseren. Neem daar dan nog een layout library bij zoals Struts Layout en je bent toch vertrokken, niet?

Overigens kan je voor Create/Update perfect hetzelfde formulier gebruiken en via Hibernate doe je dan gewoon een SaveOrUpdate();

Het probleem is dat je nog steeds enorm veel herhalend werk moet doen. En dat willen ze juist omzeilen.

[hobbit_be]

offtopic:
ben hier al een hele tijd mee bezig geweest een tijdje geleden. Het CRUD gedeelte was echter offline (Java-App). Dit gezegd zijnde: alles was wel met OJB (beetje Hibernate) gedaan en natuurlijk gebruikte het de pure definition files van hoe je data is opgebouwd (met extra tags voor "standaard" UI display zoals: hoe veel erin mag, mooi labeltje, etc.

We werkten met 39 entities en alle CURD (+ nog tientallen special actions) waren totaal transparent: de form generation kon zowel puur automatisch (ie show all met default UI) of bepaalde views konnen ook worden assigned dit mits een volledig XML based systeem. Alles werd gedaan op 1 dag. En tot op heden nog geen enkele bug report of klacht (running over 18 months).

En nu ben ik hetzelfde aan het doen in PHP (en dus on da net). Het enige wat ik het tegengekomen is DBDataObjects in PHP, maar voor de rest niets (ik geef toe naar JSP heb ik niet gekeken -> geen optie). Ben benieuwd of iemand hier wel iets heeft gevonden...

[Verwijderd]

héél veel herhalend werk, maar Spring is een mooi framework met basisklassen voor je DAO... dus kijk daar eens naar? (je hebt bijvoorbeeld appfuse als voorbeeld, lees je daar eens in).
Tenslotte zul je altijd iets zelf moeten doen hoor....(denk een beetje aan de werkgelegenheid voor de rest van ons )

[misfire]

MiddleGen kan CRUD interfaces genereren, of je kunt voor een Naked Objects oplossing gaan. In de meeste applicaties is CRUD echter een vrij beperkt onderdeel van de functionaliteit, of is één van de letters veel complexer dan normaal (bijvoorbeeld uitgebreide rapportage opties of een intelligente wizard). Een CRUD framework kan bij dat soort specialisaties dan weer in de weg zitten.

Ik zou als ik jou was kijken naar code generatie voor repetitieve onderdelen in je code. Definieer een mapping tussen je Java objecten en wat form eisen in een XML bestandje en maak een paar Velocity templates die wat Java klasses en JSP bestanden genereren. Dat is in een dagje wel opgezet en dat kun je écht inpassen in je eigen applicatie zoals je het zelf wilt.

[Alarmnummer]

Verwijderd schreef op 16 augustus 2004 @ 17:56:
héél veel herhalend werk, maar Spring is een mooi framework met basisklassen voor je DAO... dus kijk daar eens naar? (je hebt bijvoorbeeld appfuse als voorbeeld, lees je daar eens in).

Spring levert geen basis classes voor je DAO, die moet je zelf leveren. Vanaf interfaces tot implementatie. Eventueel kan hibernate meteen al een hele zwik voor je aanmaken. Wat Spring eigelijk doet is het lijm vormen tussen de verschillende layers en verder kan hij je domeinlayer oppoetsen door allerlei aspecten er aan toe te voegen zoals transacties. In 1e instantie lijkt het me erg leuk, maar volgens mij gaat dit systeem zolang je zoveel in XML files blijft rommelen, niet echt fijn meegroeien (refactoren). Pas als je vanuit metadata het meeste kan genereren en een stuk minder met XML files hoeft te bewerken... dan zal het pas prettig worden om mee te werken.

*mening van iemand die er nog geen praktische dingen mee heeft gedaan, maar er zich wel in heeft verdiept*

[Verwijderd]

Bedankt voor de eerste reacties.

Omdat er volgens mij nog niet iets bestaat wat hier op lijkt (behalve Oracle ADF) zit ik er over te denken om het zelf dan maar te gaan maken (Open source project).

Waar ik aan zit te denken is het volgende:

Ik wil het huidige Struts framework als uitgangspunt nemen (heeft zich inmiddels bewezen en beval al allerlei handige snufjes zoals validatie, internationalisatie, etc)...

Ik zou de dataklasses kunnen 'wrappen' in een universele klasse met standaard methoden zoals create, delete, update, etc... Het framework zou dan in staat moeten zijn de juiste data te laden, saven, etc...

Dit zou declaratief kunnen gebeuren. (Bijvoorbeeld d.m.v. een XML bestand per data klasse te creeeren die wordt gelezen door het framework. Op basis van reflectie kunnen dan de juiste klasses geladen worden. Verder kan de declaratie ons vertellen welke persistence engine gebruikt moet worden. (Hibernate, CMP, JDO of SQL).

Iemand een visie hierover?

[Verwijderd]

Ik zou, als je dit dan echt wilt, het springframework als uitgangspunt nemen. Vele frameworks vallen namelijk hierbinnen en struts is nou eenmaal alleen op de web kant gericht. Maar goed, ik vind het een beetje als een ordinaire OR mapping tool klinken, en die zijn er genoeg. Ik denk ook dat je op deze manier functionaliteit gaat missen. Immers een belangrijke reden om persistentie objecten te maken is om het sql gedeelte van een applicatie op een overzichtelijke manier aan de SQL programmeur over te laten.

Dus waarom niet, bijvoorbeeld, een plugin voor eclipse die wat standaard template-jes genereerd aan de hand van wat boontjes?

[Verwijderd]

Verwijderd schreef op 16 augustus 2004 @ 22:00:
Ik zou, als je dit dan echt wilt, het springframework als uitgangspunt nemen. Vele frameworks vallen namelijk hierbinnen en struts is nou eenmaal alleen op de web kant gericht. Maar goed, ik vind het een beetje als een ordinaire OR mapping tool klinken, en die zijn er genoeg.

Het is net geen ordinaire OR mapping tool. Het is een transparant mechanisme om objecten afkomstig uit elke OR mapping tool op een uniforme manier weer te geven binnen een web applicatie.

Ik denk ook dat je op deze manier functionaliteit gaat missen. Immers een belangrijke reden om persistentie objecten te maken is om het sql gedeelte van een applicatie op een overzichtelijke manier aan de SQL programmeur over te laten.

[off-tocic]
Is dat zo? Volgens mij is dat net niet het geval. In het geval van Hibernate / CMP / JDO / Cayenne etc... wordt de SQL net voor je gegenereerd.
[/off-topic]

Dus waarom niet, bijvoorbeeld, een plugin voor eclipse die wat standaard template-jes genereerd aan de hand van wat boontjes?

[/quote]
Dat zou ook kunnen, maar dat zouden dan templates zijn de bruikbaar zijn binnen mijn webapplicatie. Ik wil echter herbruikbaarheid realiseren door op een uniforme manier dataobjecten te binen aan de GUI laag.

[Alarmnummer]

Verwijderd schreef op 16 augustus 2004 @ 22:28:
[...]

Het is net geen ordinaire OR mapping tool. Het is een transparant mechanisme om objecten afkomstig uit elke OR mapping tool op een uniforme manier weer te geven binnen een web applicatie.

Eigelijk ook nog niet eens. Tenslotte zet jij zelf de DAO interfaces op en maak je eventueel een implementatie hiervan met bv hibernate. Wat Spring voor je doet is je objecten van de ene laag makkelijk kan 'aanspreken' uit de andere laag. Maar wat ik er tot nu toe van heb gezien (die beanconstructor) is het gewoon een verknipte manier om je java objecten in elkaar te plakken. Alsof java objecten opbouwen in XML nou ineens zoveel meerwaarde heeft.

Ik heb het dan niet over die AOP toevoegingen van Spring zoals het toevoegen van transacties.

[ Voor 10% gewijzigd door Alarmnummer op 16-08-2004 22:35 ]

[Verwijderd]

Dat heeft inversion of control meerwaarde. Bij het ontwikkelen kun je dan heel makkelijk verschillende implementaties van een bepaald onderdeel testen. Het houd het programma vaak transparanter.

En bij hibernate geen sql? Dat verpak je toch keurig in je XML, danwel in een aangepaste hibernate taal? Volgens mij onderkend iedere persistentie laag tool (om het maar even zo te noemen) dat je niet om sql heen kan. Je mag toch verwachten dat voor iedere create logischerwijs iets anders moet gebeuren, dus zorg dan dat je gewoon de create kan genereren uit een entiteit specificatie (en dan bedoel ik java code om verder mee te prutten)

[ Voor 5% gewijzigd door Verwijderd op 16-08-2004 22:50 ]

[Verwijderd]

Alarmnummer schreef op 16 augustus 2004 @ 18:50:
[...]

Spring levert geen basis classes voor je DAO, die moet je zelf leveren. Vanaf interfaces tot implementatie. Eventueel kan hibernate meteen al een hele zwik voor je aanmaken. Wat Spring eigelijk doet is het lijm vormen tussen de verschillende layers en verder kan hij je domeinlayer oppoetsen door allerlei aspecten er aan toe te voegen zoals transacties. In 1e instantie lijkt het me erg leuk, maar volgens mij gaat dit systeem zolang je zoveel in XML files blijft rommelen, niet echt fijn meegroeien (refactoren). Pas als je vanuit metadata het meeste kan genereren en een stuk minder met XML files hoeft te bewerken... dan zal het pas prettig worden om mee te werken.

*mening van iemand die er nog geen praktische dingen mee heeft gedaan, maar er zich wel in heeft verdiept*

eenzelfde mening (dat klein beetje gepruts telt eerlijkheidshalve niet mee )

Ik vind dat Spring enkele eenvoudige mechanismen in superklassen levert die het werken met (in mijn 'geval' , interessevlak) Hibernate toch wel flink makkelijker maken. Verder heeft het een mooie transactieafhandeling op een manier die zo een voudig is maar die ik nog nergens anders had gezien... Spring is het eerste opensource framework waar ik me in sommige delen echt in de source heb verdiept ZONDER dat ik een probleem had
En die IoC HOEF je ook niet te nemen, mits een eenvoudige superklasse van de klassen die je gebruikt kun je in elke constructor nog alle dependencies zelf even resolven, de setters zijn er al. Maar ik denk dat die XML's makkelijk zijn in sommige gevallen.

Dat wiren van die beans is inderdaad (waarschijnlijk) een pokkewerkje als je dat achteraf allemaal samen moet doen. Maar als je het gelijdelijk van in het begin direct doet zonder uitstel lukt het wel (denk ik).

Verder is er reeds wat XDoclet gegoochel mogelijk:
http://xdoclet.sourceforge.net/xdoclet/tags/spring-tags.html
als je dat moest bedoelen. (maar voor Spring vind ik dat het niet thuishoort in het source document...hibernate bijvoorbeeld wel, maar niet om er je DB uit te genereren zoals AppFuse, maar wie ben ik)

[edit]
even de link geven naar dezelfde vraag op JavaLobby, misschien komen ze daar wat verder:

http://www.javalobby.org/...threadID=13889&forumID=61

[ Voor 5% gewijzigd door Verwijderd op 17-08-2004 12:55 ]