Archief - [ALG]projectje class diagram

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
C

Candyman66

Legacy Member
Io,

Ik zit met volgende vraag: ik ben op het moment bezig met een project om een content management system te maken in java/vb.net. ik heb al een database opgesteld waar gegevens inzitten zoals users, albums, foto's en dergelijke. nu ik moet een class diagram opstellen van het hele programma. de vraag is of ik nu ook effectief een class ga nodig hebben voor bijvoorbeeld een album ? Of ga ik eerder classes nodig hebben waardat er sql-statements in komen te staan om albums toe te voegen aan de database ?

Alleen zinvolle replies aub :)

Greetz
B

Bubbling Zombie

Legacy Member
Candyman66 zei:
Io,

Ik zit met volgende vraag: ik ben op het moment bezig met een project om een content management system te maken in java/vb.net. ik heb al een database opgesteld waar gegevens inzitten zoals users, albums, foto's en dergelijke. nu ik moet een class diagram opstellen van het hele programma. de vraag is of ik nu ook effectief een class ga nodig hebben voor bijvoorbeeld een album ? Of ga ik eerder classes nodig hebben waardat er sql-statements in komen te staan om albums toe te voegen aan de database ?

Alleen zinvolle replies aub :)

Greetz
Klik om te vergroten...

ge kunt best n-tier werken: een data access laag (klassen om uw data op te halen), een business laag (uw logica - dus een album klasse , een dvd klasse etc), en een presentatielaag (uw gui)
C

Candyman66

Legacy Member
Bubbling Zombie zei:
ge kunt best n-tier werken: een data access laag (klassen om uw data op te halen), een business laag (uw logica - dus een album klasse , een dvd klasse etc), en een presentatielaag (uw gui)
Klik om te vergroten...

thanks, dat helpt mij al een beetje verder ;)
a

alva848

Legacy Member
Je zal inderdaad ongeveer voor elke tabel een klasse maken. Let wel, dat hoeft niet, maar daar komt het zo ongeveer wel op neer.
Het grote verschil zit erin dat je bij klassen wel meer-op-meer (n op n) relaties kunt hebben. Je gaat dus bv. niet je koppeltabellen modelleren in je klassediagram.

In het begin ga je dit overbodig en veel werk vinden, maar met wat inheritance valt dit best mee en gaat je programma veel robuster en flexible zijn en ga je nooit meer terug. ;)
.

.Acku.

Legacy Member
Album lijkt mij toch wel HET object in uw applicatie, daarnaast ook nog een AlbumFacade met AlbumDAO, en mogelijk een AlbumService zelfs.

Album: alle velden die je in een album hebt (titel, uitvoerder en mogelijk een lijst van AlbumTracks objecten)
Bvb: getTitle(), getId(), setTracks(List tracks)...

AlbumService: logica die interessant is voor je applicatie zoals albums vergelijken, albums opslaan, verwijderen, updaten, aantal tracks opvragen, tracks opvragen in random volgorde etc etc. Alles wat met Albums te maken geeft.
Bvb: findAlbumByTitle(Album, album, String title), randomizeAlbumTracks(Album), storeAlbum(Album), getAlbum(Integer id)

AlbumFacade: Object die uw bussiness logica van uw database scheidt, hier zet je de methodes om albums te peristeren, in een DAO (data access object) aanpak houdt dat niet mee rin als verwijzen naar uw DAO.
Bvb: storeAlbum(Album), getAlbum(Integer id), deleteAlbum(Integer id)


AlbumDAO: de eigenlijke code naar je database, de SQL statements om een op te halen, een toe te voegen ed.d
bvb: storeAlbum(Album), getAlbum(Integer id), deleteAlbum(Integer id)


Je merkt dat er heel wat gedelegeerd wordt: Store oproepen in de service roept store in de Facade die store roept in de DAO. Op die manier hoef je enkel nog met de service te werken, terwijl je later de database implentatie veilig kunt wisselen (een wijziging van een JDBC Sql DAO naar bvb Hibernate of EJB3 DAO) zonder uw bussiness logic te moeten hercoderen.

Je mag hier gerust de facade laten vallen als je wilt.

Als je zo werkt, werk je op degelijk niveau;)
C

Candyman66

Legacy Member
@ .Acku. en al de rest: heel fel bedankt voor de goeie info ! Ik ga mij hier zeker aan houden. Ik had in mijn boek van vb.net dat ik pas heb ook zoiets in die aard terug gevonden om in een 3-lagen model te werken. :)
Als ik mijn class diagram gemaakt heb dan zal ik hier wel een linkske zetten zodat ge eens kunt zien of ik in de juiste richting aan het werken ben ;)

*edit*

en dan hier de link Classdiagram

Dit is nog maar een eerste versie, dus er zullen zeker nog dingen niet juist zijn of maar half afgemaakt zijn. De verbanden tussen de classes heb ik nog niet aangeduid, dat is voor als het af is.
Geef maar gerust wat feedback, ik zal het wel horen als er iets veranderd of toegevoegd moet worden :)
a

alva848

Legacy Member
- Zet je connection object in een aparte klasse.
- insert, update, etc... kunnen in dezelfde klasse voor elk object.
B

Bubbling Zombie

Legacy Member
alva848 zei:
- Zet je connection object in een aparte klasse.
- insert, update, etc... kunnen in dezelfde klasse voor elk object.
Klik om te vergroten...

nog beter: gebruik voor je connectie te beheren een bestaand framework. Of maak er zelf een factory'tje voor
.

.Acku.

Legacy Member
Ye, is wel komisch dat hij mijn raad eigenlijk volledig genegeerd heeft.
k

killgore

Legacy Member
waarom administration en user scheiden :s?

Je hebt zo te zien een admin-login en daarnaast een usersysteem. Is het niet veel simpeler en logischer om een admin een speciale user te maken (eventueel door bepaalde flag-klassevariabele toe te voegen, puur overloading is hier overbodig).
Daarnaast, voor je album: lees .Acku. zen uitleg is, het ziet er op het eerste gezicht "ingewikkeld" uit (ik wil zeggen: complexer als gij nu doet), ma programmatorisch gezien lijkt zijn oplossing me veel beter en flexibeler :).
het kan zijn door onvolledig klasse-diagramma, ma ik zie gewoon té weinig links. Ook zou het handig zijn je db-layout in een schema te gieten en daar extra links duidelijk maken, want das ook vrij belangerijk om overzicht te behouden, want in dit systeem hangt er veel af van de db-structuur, ongeacht hoe je de programmatie implementeert. (ik heb genoeg van deze zaken in php gemaakt om da laatste te beamen ze :)).

En idd: db-afhandelingsrommel meer concentreren of gebruik bestaande zaken, als gij bv. wilt overschakelen op een ander db-systeem gade met uw huidige systeem niets dan last krijgen.
B

Bubbling Zombie

Legacy Member
killgore zei:
waarom administration en user scheiden :s?

Je hebt zo te zien een admin-login en daarnaast een usersysteem. Is het niet veel simpeler en logischer om een admin een speciale user te maken (eventueel door bepaalde flag-klassevariabele toe te voegen, puur overloading is hier overbodig).
Daarnaast, voor je album: lees .Acku. zen uitleg is, het ziet er op het eerste gezicht "ingewikkeld" uit (ik wil zeggen: complexer als gij nu doet), ma programmatorisch gezien lijkt zijn oplossing me veel beter en flexibeler :).
het kan zijn door onvolledig klasse-diagramma, ma ik zie gewoon té weinig links. Ook zou het handig zijn je db-layout in een schema te gieten en daar extra links duidelijk maken, want das ook vrij belangerijk om overzicht te behouden, want in dit systeem hangt er veel af van de db-structuur, ongeacht hoe je de programmatie implementeert. (ik heb genoeg van deze zaken in php gemaakt om da laatste te beamen ze :)).

En idd: db-afhandelingsrommel meer concentreren of gebruik bestaande zaken, als gij bv. wilt overschakelen op een ander db-systeem gade met uw huidige systeem niets dan last krijgen.
Klik om te vergroten...

Flags zou'k nie gebruiken. Wat dan als je nog een ander soort gebruiker krijgt?
H

Hale

Legacy Member
als je in java werkt kan je voor je authenticatie en authorisatie gebruik maken van het JAAS framework. Dat laat je toe om mensen te laten inloggen als een bepaalde user en ook om eenvoudig at runtime te checken of de gebruiker wel de nodige permissies heeft om een stuk code uit te voeren ( technisch gezien laat het je toe de accesscontrolcontext die gebruikt wordt bij stack walking aan te passen zodat deze de huidige user voorstelt ).

volgende links geven er uitleg over :

http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASRefGuide.html
http://java.sun.com/products/jaas/overview.html

misschien een beetje overkill voor wat je nodig hebt, maar op die manier ben je wel zeker dat je authenticatie deel mooi afgeschermd blijft van je business logica, wat wel eens anders is als je zelf alle authenticatie crap van nul bouwt...
k

killgore

Legacy Member
Bubbling Zombie zei:
Flags zou'k nie gebruiken. Wat dan als je nog een ander soort gebruiker krijgt?
Klik om te vergroten...
Nieuwe flag toevoegen? Met long kunde 64 flags gebruike, is toch al vrij veel zu :p. (ik bedoel dus bitmasks he ;)).

ma twas maar vb. he :), der bestaan wel andere oplossingen die mssch beter zijn voor dit project, ma ik vind bitmaks gewoon handig om beperkte informatie op te slaan :), zoals ek zei: ge kunt 64 masks hebben (en combinaties maken offcourse), is voor meeste systemen genoeg en als ge niet meer moet hebben om toegang te verkrijgen vind ek gaan overerven e.d. wa overpower.
Natuurlijk, als hij een onbeperkt aantal mogelijkheden wilt toevoegen voor status/mogelijkheid van een gebruiker wegens functionaliteit van de CMS dan moet em voor andere oplossing gaan ;).
C

Candyman66

Legacy Member
@ killgore and hale

ik ga daar volledig mee akkoord met hetgene dat ge allebei zegt, maar het hoeft zo ingewikkeld niet te zijn voor ons project. Ik heb nog nooit met zulke dingen gewerkt dus eer dat ik het goed ga begrijpen dan is het waarschijnlijk al te laat om het te implementeren ;)

*edit*

classdiagram geupdate: classdiagram
.

.Acku.

Legacy Member
Candyman66 zei:
@ killgore and hale

ik ga daar volledig mee akkoord met hetgene dat ge allebei zegt, maar het hoeft zo ingewikkeld niet te zijn voor ons project. Ik heb nog nooit met zulke dingen gewerkt dus eer dat ik het goed ga begrijpen dan is het waarschijnlijk al te laat om het te implementeren ;)

*edit*

classdiagram geupdate: classdiagram
Klik om te vergroten...

Niet voor het een of het ander he, maar ObjectDAO, ObjectFacade en ObjectService zijn afgesproken begrippen qua naamgeving. Je hoeft jezelf niet origineel en creatief te voelen en ineens exotische namen uit te vinden zoals DatabaseService en AlbumManagement.
herkenbaarheid primeert op het artistieke ;)
C

Candyman66

Legacy Member
.Acku. zei:
Niet voor het een of het ander he, maar ObjectDAO, ObjectFacade en ObjectService zijn afgesproken begrippen qua naamgeving. Je hoeft jezelf niet origineel en creatief te voelen en ineens exotische namen uit te vinden zoals DatabaseService en AlbumManagement.
herkenbaarheid primeert op het artistieke ;)
Klik om te vergroten...

Ja ik weet het, ge hebt gelijk :) Ik heb ze deze namen enkel gegeven omdat onze lector zei dat het zo goed was. Om eerlijk te zijn heb ik nog niet van ObjectFacade gehoord (kan nog wel komen in de toekomst) dus mss dat ze zich vragen gaan stellen als ik opeens met zo een termen ga afkomen :p
.

.Acku.

Legacy Member
Is denk ik juist wat ge zou moeten willen, dat ze hun daarover vragen stellen. Research (goede research) is een van de skills die een goede programmeur moet hebben, een must. Een toonbeeld van maturiteit ;)
B

Bubbling Zombie

Legacy Member
killgore zei:
Nieuwe flag toevoegen? Met long kunde 64 flags gebruike, is toch al vrij veel zu :p. (ik bedoel dus bitmasks he ;)).

ma twas maar vb. he :), der bestaan wel andere oplossingen die mssch beter zijn voor dit project, ma ik vind bitmaks gewoon handig om beperkte informatie op te slaan :), zoals ek zei: ge kunt 64 masks hebben (en combinaties maken offcourse), is voor meeste systemen genoeg en als ge niet meer moet hebben om toegang te verkrijgen vind ek gaan overerven e.d. wa overpower.
Natuurlijk, als hij een onbeperkt aantal mogelijkheden wilt toevoegen voor status/mogelijkheid van een gebruiker wegens functionaliteit van de CMS dan moet em voor andere oplossing gaan ;).
Klik om te vergroten...

Kutn beter nen interface user maken en die dan laten implementeren door uw user & administrator :p
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan