Een framework dat standaard applicatietaken uitvoert

[Verwijderd]

Hoi

Ik heb een vraag over systeemontwerp. Eigenlijk alleen uit belangstelling, omdat ik de tijd niet heb om uitgebreid aan het programmeren te gaan.

Je hebt in elke applicatie algemene taken, zoals invoercontrole, database access, misschien XML ophalen en formateren, foutmeldingen weergeven, etc.

Je hebt in elke applicatie ook applicatiespecifieke klasses. Deze hebben betrekking op de specifieke situatie waar de applicatie voor geschreven is. Zo heb je voor een bakker misschien een Taart klasse en voor een garage een "Klant" en een "Auto" klasse.

Hoe kun je je applicatie nou onafhankelijk maken van de applicatiespecifieke data? Wat ik eigenlijk wil is een applicatie waarin ik nooit een applicatiespecifieke klasse hoef te instantieren. Tenminste, niet zelf in de code. De code van mijn applicatie moet dat dynamisch doen. Ik heb zoiets op kleine schaal gemaakt met de Java reflection API. Deze API is volgens de documentatie alleen erg langzaam en niet geschikt voor stukken code die regelmatig aangesproken worden en dat is bij mij natuurlijk wel het geval. Ik ben ook een paar ORM layers tegengekomen, maar heb ze nog niet gebruikt. Zo'n ORM layer lijkt me een prachtige aanpak om je applicatie los te maken van de specifieke situatie. Maar ook hier zie ik een hoop vraagtekens bij de performance.

[ Voor 5% gewijzigd door Verwijderd op 19-07-2008 00:03 ]

[LauPro]

Je moet een duidelijke scheiding maken tussen het platform, framework en de applicatie. Als je meerdere applicaties hebt (bijvoorbeeld een frontend voor de klant en een backend voor de agent) dan zal je misschien dit willen delen in een framework. Uiteindelijk blijven alle applicaties afhankelijk van elkaar als ze binnen hetzelfde domein moeten opereren.

Als ik je goed begrijp wil je dus alle logica in een framework/library stoppen en dan je applicaties puur de GUI/user input laten doen. Klinkt een beetje als het websiteconcept.

[Verwijderd]

Het is niet helemaal een website concept denk ik. Het maakt in feite niet echt uit waar de display plaatsvindt. Ik dacht meer richting een ORM -achtig systeem. Iets dat tussen de applicatie en de database zit.

Misschien is een voorbeeld handig:

Ik wil op mijn website (toch een website) auto's beheren. Ik wil ze kunnen weergeven, aanpassen, sorteren, zoeken, etc. Ik sla daarvoor autogegevens op in de database. Om al deze taken te kunnen faciliteren heb ik formulieren nodig, invoercontroles, weergavecode, database queries, etc. Deze dingen wil ik echter niet hoeven aanpassen als ik morgen besluit dat ik ook boten, of fietsen wil toevoegen aan het verhaal. Formulieren, invoercontrolers en queries moeten allemaal gegenereerd worden op basis van de eigenschappen van het Type waarmee gewerkt wordt.

Ik heb iets dergelijks proberen te maken met reflectie. Je kunt met reflectie
on the fly' tijdens runtime objecten aanmaken. De applicatie vraagt een set autorecords op uit de database en bouwt met behulp van reflectie van deze ResultSet een List met Objecten. Deze objecten worden door de programmeur gecast naar Auto en de applicatie kan hier vervolgens mee aan de slag, dat wil zeggen weergeven, sorteren, etc. (Ik heb geprobeerd de applicatie de casting zelf te laten doen, maar dat kreeg ik niet voor elkaar)

[ Voor 24% gewijzigd door Verwijderd op 19-07-2008 01:09 ]

[LauPro]

Dan moet je er óf voor kiezen om seperate bronbibliotheken te handhaven óf een generiek model te schrijven waar je vervolgens conform je definities de parameters bepaalt.

[Razr]

Heb je het nou niet gewoon over 'Design Patterns'? Volgens mij is reflection helemaal niet nodig voor wat jij wil bereiken.

[ Voor 8% gewijzigd door Razr op 20-07-2008 17:35 ]

[Tuxie]

Bij een 'beetje' enterprise achtige applicatie wordt dit standaard al gebruikt hoor. Waar jij het over hebt is dat je op zoek bent naar een algemeen model om persistente data op te slaan. Over het algemeen komt een ORM al dicht in de buurt voor hetgeen jij wilt. Wat veel gebruikt wordt zijn 'hibernate' achtige oplossingen: op het laagste niveau de DB, daarbovenop JDBC achtige zaken en daarbovenop Hibernate. Deze hibernate objecten bevatten informatie over DB types (b.v. mysql types) maar kan deze ook vertalen naar b.v. java types. Op deze manier kun je makkelijk switchen van DB / connector / programmeertaal. Zo is Oracle i.c.m. C++ of .NET ook weer mogeliik.

Als je slim bent schrijf je daar een stukje code bij die automatisch je invoer checkt. Dus als jij een constraint hebt staan op een datum (YYYY-MM-DD) dan moet de applicatie validatie code ook automatisch gegenereerd worden. Dit is allemaal mogelijk en niet echt rocket-science. Tenminste, als het m.n. om CRUD applicatiezaken gaat.

[dingstje]

Waarom hebben zoveel mensen het zo moeilijk met code? Daar is toch niks mis mee? Het is nu eenmaal zo dat programmeertalen een uitstekend middel zijn om processen te beschrijven. Voor repetitieve taken zoals standaard DB access, authentication/authorization, formuliertjes tekenen e.d. kan/moet je gebruik maken van standaard libraries om tijd te besparen. Maar met een dergelijk generiek systeem zal je geen tijd besparen in ontwikkeltijd eenmaal je met iets complexere zaken begint, en al zeker niet in execution time van je applicatie.

[HawVer]

Wat dingstje zegt ben ik het mee eens. Uiteindelijk sla je er zover in door dat je alleen nog maar verantwoordelijkheden aan het verplaatsen bent naar een hoger niveau. Als je een simpel dataset gebruikt en die weergeeft in een grid maakt het niet uit wat het dataset bevat. Het grid zal zelf wel bepalen hoe hij het moet weergeven. (Bijvoorbeeld)

Er worden ook een aantal ORM suggesties genoemd, maar ook die vereisen van je dat je object model van tevoren vast ligt. Dus runtime bepalen hoe een object er uit komt te zien gaat niet lukken. Een ORM is bedoeld om object model los te koppelen van je database model. De object model ligt vast voor je gaat compileren.

[LauPro]

dingstje schreef op zondag 20 juli 2008 @ 20:21:
Waarom hebben zoveel mensen het zo moeilijk met code? Daar is toch niks mis mee?

Het punt blijft gewoon dat in het kader van onderhoudbaarheid en portabiliteit (ook naar nieuwe platformversies) business logic gewoon eng is. Het zorgt voor een hoge mate van afhankelijkheid van je platform en vaak voor problemen mbt schaalbaarheid.

Op het eerste gezicht is dat niet erg maar als een applicatie zich verder ontwikkelt loop je steeds sneller tegen die grenzen aan, wat niet alleen lastig maar ook vooral eentonig en vervelend werk geeft.

Vanuit een aannemersoogpunt is dat niet allemaal niet zo erg, het levert toch werk op. Maar als developer wil je natuurlijk zo min mogeiljk bezig zijn met het onderhoud en afstellen van je applicatie.

[wasigh]

Wat je wilt is inderdaad een framework bouwen, om te zorgen dat je verschillende soorten objecten kunt ondersteunen moet je zorgen dat je niet direct met de objecten werkt maar met de metadata over die objecten. In die metadata neem je dan de gegevens op die voor jou interessant zijn. Zoals je aangeeft kun je dat doen met reflectie, andere frameworks gebruiken er vaak ook XML structuren voor of annotations/attributes

Het is dan aan jou om het optimaal te tunen voor performance. Ik kan me voorstellen dat je de eerste keer dat je een Object gebruikt een metadata file genereert via Reflectie en daarna die file gebruikt.

In je framework ondersteun je dan het model wat jij interessant vind, alleen kom je dan bij het grote nadeel van modellen: het is altijd een versimpelde weergave van de werkelijkheid. Op een gegeven moment loop je tegen een grens aan die je niet in het model kwijt kunt en dan is de vraag: bouw ik het model uit of niet? Wat er dan vaak gebeurt is dat het model steeds groter en complexer wordt en je uiteindelijk beter af bent het gewoon coderen van je applicatie in plaats van alles te willen modelen.

Frameworks zijn heel handig voor voorspelbare acties (CRUD, formulier generatie etc) maar voor de spannende dingen zou ik toch gewoon code pakken.

(en code is natuurlijk ook al gewoon een model, waarom zou je dat niet gewoon gebruiken?)

[.oisyn]

offtopic:
wasigh tijd niet gezien

@hieronder

Face_-_LeSS schreef op maandag 28 juli 2008 @ 20:16:
Als ik later groot ben... wil ik mod worden

offtopic:
Been there, done that, got the T-shirt

[ Voor 73% gewijzigd door .oisyn op 29-07-2008 00:07 ]

[Face_-_LeSS]

.oisyn schreef op maandag 28 juli 2008 @ 18:25:

offtopic:
wasigh tijd niet gezien

MOD BREAK:
Algemene FAQ / Een reactie plaatsen

• ...
• Hou reacties ontopic
• ...

Als ik later groot ben... wil ik mod worden

[wasigh]

.oisyn schreef op maandag 28 juli 2008 @ 18:25:

offtopic:
wasigh tijd niet gezien

offtopic:
.oisyn idd, ik lurk tegenwoordig vooral /31 en /61 en ik dacht: ik zal weer eens een kijkje nemen. Grappig om te zien dat er nog steeds oude rotten rondhangen Ik las een mooi verhaal over optimalisatie van je, heb ik toch weer wat geleerd vandaag!

[MSalters]

Eerlijk gezegd heb ik op mijn prive PC en werk PC geen enkele applicatie die aan jouw beschriving voldoen. Want bij allemaal ontbreekt de database, invoercontrole, foutmeldingen weergeven of een ander zogenaamd essentieel element. Soms zelfs meerdere van die elementen.
Sterker nog, ik heb kleine applicaties die niets anders doen dan 1 of 2 applicatie-specifieke classes te instantiëren, te runnnen, en de output weg te schrijven.

Overigens - het is natuulijk theoretisch onmogelijk dat je een applicatie maakt zonder zelf een applicatie-specifieke klasse te instantiëren in pure OO talen. De standaard classes gaan namelijk niet jouw classes zomaar instantiëren, daar zul jij zelf toch opdracht voor moeten geven. Om in jouw voorbeeld te blijven: Waar zit de code die de Java reflection API aanroept?

[_Erikje_]

Je wilt dus runtime objecten aan kunnen maken. Dit lijkt me goed te doen in een dynamische programmeertaal. Misschien is Groovy wel iets om naar te kijken.
Grails (de ruby on rails voor Groovy) zorgt voor al je ORM dingetjes en via validators kan je al je input checks laten doen.
Kijk even naar de advanced user guide.