Alarmnummer schreef op zaterdag 12 februari 2005 @ 12:27:
Mee eens. En ik gebruik een oo domein model omdat het veel krachtiger is dan een relationeel model. Alles wat een relationeel model kan, kan een oo model ook.. en meer. Ik zie niet in waarom ik me zou moeten beperken tot een mindere oplossing.
In een relational model zit geen behavior, dus het is appels met peren vergelijken.
Als ik weet dat een stuk dat niet vanuit een andere context aangesproken hoeft te worden, waarom zou ik dan voor de meest universele oplossing gaan? Ik ga dan voor de oplossing die mij het minste tijd zou moeten kosten en niet een waar ik steeds naar een universeel model toe ga werken.
Van DAL naar BL is al context-switching en van BL naar GUI ook. Jij wilt DAL <-> BL zo oplossen dat je dan dezelfde contexts gebruikt maar dat kan niet, want je beperkt jezelf tot subset definities op alleen objects.
Ga maar eens een reporting systeem bouwen met een pure o/r mapper en alleen een domain model.
Dat is precies wat ik met dit topic wil zeggen. Als je weet dat data niet vanuit een andere context aangesproken gaat worden, waarom dan de extra kosten betalen??
Kijk naar je domainmodel: zit er 1 entity in die een property heeft die data teruggeeft van een related entity, bv order.companyname? Indien ja: dan heb je al context verschillen. Heeft je applicatie lijstjes nodig op het scherm? Indien ja, dan heb je al context verschillen. De meeste db driven apps gebruiken lijstjes in schermen. Het is dan jezelf alleen maar moeilijk maken om dan krampachtig vast te blijven houden aan "Maar ik gebruik objects!". Wees toch eens wat flexibeler!
Hmm tja.. maar er zijn genoeg mensen die juist erg voor domein modellen zijn
En die ook nog eens object georienteerd zijn. In je domein model geef je een reflectie van de werkelijkheid. En hierbij heb je soms de behoefte aan een stuk overerving...
... het is geen reflectie van de werkelijkheid want zoals Evans zei: je hebt een translatie nodig tussen functioneel ontwerp en je domain model. (hij pleit voor een taal daarvoor). Nu kan het aan mij liggen maar als je vertalingen nodig hebt tussen functionele beschrijvingen en je applicatie structuur (dus 'functionaliteit A' is gebouwd middels deze object graph en dit stukje code hier in object a en d) lijkt het mij dat je niet echt goed bezig bent maar dat is een andere discussie. IMHO is het modelleren van de processen die de software gaat automatiseren naar die processen beter dan een vertaling daarvan te maken, omdat je functionele beschrijvingen dan niet 1:1 kunnen worden afgebeeld op je code zodat je niet van functionele beschrijving naar code kan in 1 stap en vice versa.
Ik heb het al meerdere keren gezegd en begin er nu toch wel een beetje flauw van te worden. Soms heb je data dat niet vanuit een andere context aangesproken gaat worden. Als aan deze voorwaarde is voldaan, dan is een 'beperkter' alternatief zoals een ODBMS imho een betere oplossing doordat het minder tijd kost want je zit tenslotte ook in een oo omgeving (dus er hoeft geen paradigma vertaling plaats te vinden).
Tja, dan word jij daar maar flauw van. Jij begint een thread, ik geef antwoord. Ik zeg altijd: als je het antwoord niet wilt horen, moet je de vraag niet stellen.
Ik snap je redenering wel, alleen je gaat aan dingen voorbij. Waarom denk je dat ik dingen als TypedLists heb ingebouwd en mogelijkheden zodat je zelf dynamische sets kunt bouwen uit entity fields? Niet omdat ik niets te doen had, maar omdat het de power van een RDBMS in jouw handen geeft. Immers: je kunt dan niet alleen sets definieren op OBJECT sets, maar ook sets over attributes, in verschillende entities, dus veel MEER sets dan je kunt met louter objects. Nu kun jij zeggen: dat heb ik niet nodig, maar dat lijkt me echt sterk, tenzij je je GUI's e.d. zo bouwt dat je er louter single-type objects in kunt gebruiken, maar dan zijn die gui's IMHO niet zo bruikbaar.
Stel dat ODBMS`en de standaard waren en ik zat in bv een volledig procedurele omgeving. Dan zou ik als aan die voorwaarde (geen andere context) is voldaan, misschien voor een RDBMS zijn gegaan doordat hier de geen paradigma vertaling hoeft plaats te vinden.
Nogmaals, ik snap die redenatie wel, maar je gaat aan dingen voorbij. Ik heb die metafoor over domain model -> Gui schermen niet voor jan doedel hier neergezet. Een BL tier bouw je met andere dingen als eis dan een GUI, een GUI gebruikt wellicht andere sets dan de BL tier. Jij kunt nu beweren "NEE!" maar dat lijkt me echt sterk. Immers: geen order scherm zonder customer gegevens. En daar ga je al.
Jij bent de enigste die ik ken dit dit woord gebruikt. Ik heb er nog nooit van gehoord.
Nooit van gehoord? Hoe doe jij dan je informatie analyse? "Dit veld lijkt me wel logisch hier" ? Dat lukt wellicht nog wel bij een tabelletje of 10, 20. Maar voor een onderhoudbaar systeem heb je wel andere middelen nodig: abstractie bv. Je moet analyseren hoe je data zich tot elkaar verhoudt. Alleen DAN kun je op de JUISTE plek wijzigingen aanbrengen wanneer die nodig zijn, bv na een jaar in productie te hebben gedraaid.
Hmmm.. wie heeft er hier nou een OR mapper gemaakt
Ik heb niet een pure O/R mapper gemaakt maar een O/R mapping gebruikend framework. Dat is wat anders en met een reden
Wie had dus nu de behoefte om objecten in een db op te slaan? Wie loopt er nu zo hard te vechten tegen het paradigma verschil tussen een oo systeem en een relationeel systeem dat je daar zelfs je brood mee bent gaan verdienent.
Ik heb de behoefte niet om objects in een database op te slaan. Ik heb de behoefte om entities (dwz, de data die een 'customer' vormt bv) op te slaan in de database enerzijds en functionaliteit om met die data te werken anderzijds. Daarom werk ik ook met entities, niet met objects. Entities worden IN objects gerepresenteerd in memory, maar daar houdt het niet op, want je kunt veel meer met die data: je kunt sets definieren over die data en daarmee werken, om maar wat te noemen. En op dit moment gaat het nog niet ver genoeg. Ik wil bv dingen kunnen ophalen als:
SQL:
1
2
3
4
5
6
7
| SELECT O.*,
(
SELECT MAX(UnitPrice * Quantity) AS HighestPrice
FROM [Order Details] od WHERE Od.OrderID = O.OrderID
) AS HighestPrice
FROM Orders O
WHERE O.CustomerID = 'CHOPS' |
Dat kost me nu veel queries en met objects krijg ik dat er niet uit, dat moet met sets over attributes.
Met DIE power krijg je pas ontwikkelsnelheid, want de developer kan meteen alles bouwen wat hij moet bouwen zonder politiek gezeik over procedures dit of mag niet zus.
Ik heb een BOF sessie gehouden over O/R mapping op Teched vorig jaar. 1 ding kwam daar sterk naar voren: men had de behoefte om in de gehele applicatie dezelfde soort data-access technologie te gebruiken, dit voor consistentie in de applicatie (dus dat je niet met 2 soorten objects zit te zeulen, de ene moet via die DAL en de andere moet via die DAL).
In erg veel applicaties zit reporting, al dan niet middels lijstjes op schermen. Dat is erg inefficient met pure o/r mappers omdat je dan met objects moet werken, terwijl je even een setje data wilt ophalen.
(edit: verduidelijking). Die behoefte aan 1 enkele data-access technologie was voor velen niet echt te rijmen met pure O/R mapping technologie omdat data analysis en reporting bv 2 zaken waren waar pure o/r mapping niet echt tot zn recht komt en eerder een nadeel is.
Wat jij wilt echter is dat je overal in je applicatie data hebt in dezelfde context. Maar dat werkt niet, want je applicatie mag als geheel dan wel 1 applicatie zijn, de data IN die applicatie is niet altijd in dezelfde context aanwezig. (Order alleen, Order in een set van orders voor customer X, Order op een order report, Order als onderdeel van het totaal op een totals page. enz.). Omdat je dat wel wilt, (en je weet zelf al dat jouw domainmodel er anders uitziet dan je schermen (hoop ik)) loop je tegen problemen op.
Dit snap ik niet.
Wat snap je precies niet aan?
Dat klopt niet. Ik zoek een oplossing die zo weinig mogelijk tijd kost en voldoet aan mijn voorwaarden. Ik denk dat een ODBMS in sommige gevallen een goedkopere oplossing (qua ontwikkeltijd) is dan een RDBMS omdat er geen vertaal slag hoef plaats te vinden. Daarom is een ODBMS vanuit een oo omgeving de goedkoopste oplossing. Niet omdat de programmeurs te heilig geloven in OO...
Ten eerste is de behoefte aan een ODBMS alleen daar in een OO applicatie. Ten tweede is een ODBMS alleen efficient wanneer je louter objectsets definieert. Bij 9 van de 10 applicaties heb je daar niet genoeg aan, je hebt dan ook behoefte aan sets die gedefinieerd zijn over attributes van verschillende entities. Dit komt omdat in een GUI bv of in een process dat reporting data fabriceert of data analyse doet, je met lijstjes werkt die samengesteld zijn uit attributes van verschillende entities. En met objects alleen heb je dan een probleem, want je moet dan een nieuw object definieren maar hoe ga jij dat vullen met bestaande data uit 3 of 4 entities?
[
Voor 3% gewijzigd door
EfBe op 12-02-2005 13:48
]
:strip_exif()/u/31626/eend.gif?f=community)
/u/39810/danone.png?f=community)
/u/107051/jeroenmadtrix60.png?f=community)
.
/u/24089/evilbonzi-eye-dawuss-v2.png?f=community)
:strip_icc():strip_exif()/u/27686/got.jpg?f=community)
:strip_exif()/u/22119/ch.gif?f=community)
:strip_icc():strip_exif()/u/10526/avatar.jpg?f=community){kind=avatar}
/u/27299/hoofd.png?f=community)
/u/31230/crop64b060d01fd80_cropped.png?f=community)
:strip_exif()/u/80759/monstermania_small.gif?f=community)
:strip_icc():strip_exif()/u/1857/crop5a4d06ced6afe_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/32734/crop5ee11f3ba965d_cropped.jpeg?f=community)