-
13-08-2011, 11:29 #16Approved 9liver
- Registered
- 18/01/04
- Location
- Melle
- Posts
- 10,535
- iTrader
- 56 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 27/102
Ik kan je jammer genoeg niet op weg zetten met gratise varianten. Ik heb zelf enkel ervaring met een commercieel pakket dat ook nog eens zwaar overkill is voor wat jij nodig hebt en toch wel een grote instapdrempel heeft.
Ik heb altijd het gevoel gehad dat het goed werkt als je héél goed weet waar je met bezig bent. Dat is dan ook direct het nadeel dat onder andere in dat document wordt beschreven, je moet de abstractie van het systeem heel goed beheersen voor je het echt goed kan gebruiken. Vaak is die abstractie een pak complexer dan wat het abstraheert. Dat is een situatie die productiviteit eigenlijk laat dalen ipv laat stijgen. Je bent in sommige situaties waarschijnlijk meer tijd kwijt om het ORM systeem te beheersen terwijl je met een zelf geschreven SQL statement de oplossing veel sneller had gehad.
Uiteraard voor de TS die waarschijnlijk heel weinig relaties zal hebben en verre van complexe data zal een simpel ORM systeem voldoende zijn. Want meer dan wat select en update statements zal hij wel niet tegenkomen.“In terms of how we evaluate schooling, everything is about working by yourself. If you work with someone else, it’s called cheating. Once you get out in the real world, everything you do involves working with other people.”
PSN: Cycloon - Final Fantasy XIV: A realm reborn characterno votes
-
-
13-08-2011, 12:24 #17Crew Member
- Registered
- 01/09/02
- Location
- Peutie
- Posts
- 7,664
- iTrader
- 0
- Mentioned
- 4 Post(s)
- Reputation
- 13/105
Vanaf nu gaan we verder op BeyondGaming!
In deze thread wordt uitgelegd hoe je jouw account kan migreren.no votes
-
13-08-2011, 12:50 #18
hey,
aangezien ik momenteel een zicht heb op een drietal tabellen (persistente klassen: product, klant & "transactie/aankoop") is het dus idd geen complexe database structuur, al zit ik wel met het feit dat er per aankoop meerdere producten kunnen zijn en een product bij meerdere transacties kan horen: veel op veel relaties die vermeden moet worden bij relationele databanken :o - daar moet ik dus nog iets op vinden
groeten
edit: SQL heb ik ook al enkele jaren gehad dus is niet nieuw voor mij, dus miss beste om het toch bij sql statements te houden?The only real voyage of discovery consists not in seeking new landscapes but in having new eyes.no votes
-
13-08-2011, 15:58 #19
Misschien ook interessant om te weten is wat voor een applicatie het gaat worden en in welke design taal het geschreven wordt? Opteert ge voor een desktop of web applicatie?
In geval van desktop kunt ge nog kiezen om te programmeren in WinForms, WPF en Silverlight. Wanneer ge dan weer kiest voor een web applicatie zult ge sterker naar Asp.NET of Silverlight leunen. Merk op dat Silverlight voor zowel desktop als web applicaties gebruikt kan worden, wat misschien toekomstgericht meer voordelen biedt voor uw klant.
Afhankelijk van deze keuze kan al gemakkelijk tips gegeven worden over gebruikte ontwerpmethodieken... MVC, MVVM, MVP, ... het gebruiken van MEF, Prism, Unity, etcetera.no votes
-
14-08-2011, 13:45 #20Member
- Registered
- 17/07/02
- Location
- Wilrijk
- Posts
- 1,994
- iTrader
- 2 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 9/16
idd NoSql document databasesAls je gewoon de data wil opslaan, en sommige data is uitstekend geschikt voor in een database, maar je wil geen uren spenderen aan een database tabel design, omdat je eigenlijk kan uitgaan van uw implementatie, dan zijn er betere systemen dan BLT.
Zit de laatste 5 jaar regelmatig grote applicatie gemaakt met nHibernate in de vuilbak te gooien om compleet te herschrijven (met blt) in minder tijd en met veel betere performance, applicaties die nog maar 1,5 jaar in produktie staan of die gewoon UAT niet doorkomen wegens te slechte performance.Tools zoals DataObjects schermen het hele SQL gebeuren van u af, en gaan uit van uw data model. Ik heb er een dik half jaar mee gewerkt, in een vrij complexe applicatie structuur en ik kan u verzekeren dat het toch wel goed werkt.
Zaken moeten niet goed werken voor U, maar voor de gebruiker. "Toch wel goed werkt" is in mijn ogen niet goed genoegno votes
-
14-08-2011, 14:17 #21Crew Member
- Registered
- 01/09/02
- Location
- Peutie
- Posts
- 7,664
- iTrader
- 0
- Mentioned
- 4 Post(s)
- Reputation
- 13/105
En ik ben ervan overtuigd dat er ook applicaties bestaan die met BLT ontwikkeld zijn en in hetzelfde schuitje zitten. Slecht design, slechte ontwikkeling en bijgevolg een niet performante applicatie. En er bestaan nHibernate applicaties die wel performant zijn en die een goed design hebben. Dat is allemaal relatief.In mijn geval heeft de gebruiker geen weet over hoe de data wordt opgeslagen en beheerd. Die moet dat ook niet weten. De enige vragen die er voor ons toe doen zijn performantie en eenvoudig design voor de developers. En daar was BLT niet de beste keuze voor. Wel qua performantie, maar niet qua manier van ontwikkelen. Wij willen onze data eenvoudig opslaan, en momenteel gebeurt dit binair, maar een database is beter. En de eenvoudigste, duidelijkste en performante oplossing die wij vonden, waar iedereen zich in kon vinden was DataObjects.
Vanaf nu gaan we verder op BeyondGaming!
In deze thread wordt uitgelegd hoe je jouw account kan migreren.no votes
-
14-08-2011, 14:17 #22Member
- Registered
- 17/07/02
- Location
- Hasselt
- Posts
- 2,970
- iTrader
- 0
- Mentioned
- 0 Post(s)
- Reputation
- 0/18
Ik heb het eerste artikel gelezen en moet toegeven dat de schrijver ergens een punt heeft. Echter heb ik het gevoel bij het lezen dat hij een beetje is vastgeroest in programmeertechnieken van 10-15j geleden. En heel sceptisch staat tegenover nieuwe dingen die hij niet gewoon is. Door ORM direct af te schilderen als een anti-pattern geeft hij mij de indruk weinig ervaring te hebben met echt complexe systemen.
Ja, ORM is initieel simpel en vereist weinig aandacht voor de db bij kleinere applicaties.
En ja, bij daarna wordt het complex en moet ge met veel rekening houden als ge met grotere applicaties bezig zijt.
Het doel van ORM is om komende van uw DB zo snel mogelijk met objecten (entities) te werken. Uw code moet zoveel mogelijk DB-unaware zijn, ma da wil niet zeggen dat de developer de DB zo maar even moet vergeten.
Als ge dat niet doet gaat ge nooit volledig OO kunnen werken en zeker niet Domain Driven en gaat uw code naar mate uw applicatie groeit minder beheersbaar en minder overzichtelijk worden.
Ik heb toch al wat software geschreven in mijn leven, en de kracht van ORM-frameworks kwam echt naar boven bij echt complexe en grote projecten. En geloof me, ORM heeft daar zeker een ROI. Echter, als ge denkt dat ORM alles voor u gaat oplossen zal dat idd zeer vroeg in uw gezicht ontploffen. En dan begrijp ik waar de frustratie vandaan komt.
En neen ORM is geen silver bullet, die dingen bestaan niet in software engineering.If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilizationno votes
-
14-08-2011, 14:24 #23Member
- Registered
- 17/07/02
- Location
- Hasselt
- Posts
- 2,970
- iTrader
- 0
- Mentioned
- 0 Post(s)
- Reputation
- 0/18
Als ge niet weet hoe (n)Hibernate werkt, hoe en wanneer er gecached wordt, lazy loading gedaan wordt, wanneer ge N+1 zaken aan uw broek hebt zal uw performantie idd drastisch omlaag gaan.
Veel developers zijn verbaasd als ze 1000 records naar objecten binnensleuren (meestal onbewust) en er eigenlijk maar 200 nodig hebben dat de perfomantie slecht is. En dan gaan ze rap zeggen dat ORM sucked ja :PIf builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilizationno votes
-
14-08-2011, 19:05 #24Approved 9liver
- Registered
- 18/01/04
- Location
- Melle
- Posts
- 10,535
- iTrader
- 56 (100%)
- Mentioned
- 0 Post(s)
- Reputation
- 27/102
Dit is dan ook het échte probleem dat wordt aangekaart ivm ORM. Je moet meer investeren om de abstractie te begrijpen terwijl rechtstreeks werken met wat geabstraheerd wordt eigenlijk vlotter zou werken. Daarom dat het een anti-pattern is, het lijkt een groot voordeel te zijn, maar uiteindelijk moet je héél veel kennis hebben van het systeem voor je een complex probleem toch performant kan oplossen. Je kan dan wel trots zijn dat je alle in en outs kent van je ORM systeem, maar eigenlijk heb je daardoor uiteindelijk verloren (zowel tijd als geld). Het is een beetje zoals trots zijn dat je een kaartenhuis van 10 etages kan bouwen, maar in realiteit heb je daar niks aan.
“In terms of how we evaluate schooling, everything is about working by yourself. If you work with someone else, it’s called cheating. Once you get out in the real world, everything you do involves working with other people.”
PSN: Cycloon - Final Fantasy XIV: A realm reborn characterno votes
-
16-08-2011, 10:08 #25
Nogmaals allemaal bedankt voor de antwoorden
.
Ik wil het schrijven in C# en als een desktop applicatie (webapplicatie heeft atm ni veel voordelen), dus laat maar weten welk je denkt dat interessant is (welke design environment? (visual studio?) en welke methodiek is interessant? en welke extra frameworks fzo interessant zijn)?
en wat denken jullie dan dat het best wordt voor de databank? gewone SQL database (kan ik maken via visual studio)
maar als het dan een gewone relationele databank wordt zit ik nog wel met dat relatie probleem dat ik in mijn vorige post vermeldde ?
groeten !
edit: het is software voor een kapsalon
The only real voyage of discovery consists not in seeking new landscapes but in having new eyes.no votes
-
16-08-2011, 14:00 #26Member
- Registered
- 23/11/03
- Location
- Landeurp
- Posts
- 1,791
- iTrader
- 0
- Mentioned
- 0 Post(s)
- Reputation
- 10/17
no votes
-
16-08-2011, 15:01 #27
in een relationele databank moet je een veel-op-veel relatie omvormen naar 3 tabellen, maar het zou interessant zijn moest de koppelingstabel enige functie/nut/betekenis hebben (maar die heb ik dus nog niet gevonden)
tabellen: klant, "beurt", producten, behandelingen
een beurt gaat altijd gekoppeld zijn aan 1 klant (dus 1 klant kan meerdere beurten hebben maar 1 beurt kan maar 1 klant hebben, dus een één-op-veel relatie daartussen)
tussen beurten, producten en behandelingen zitten echter veel op veel relaties (1 beurt kan uit meerdere behandelingen bestaan + meerdere producten)The only real voyage of discovery consists not in seeking new landscapes but in having new eyes.no votes
-
16-08-2011, 15:45 #28Approved 9-lifer
- Registered
- 31/07/04
- Location
- Kortrijk
- Posts
- 1,019
- iTrader
- 4 (100%)
- Mentioned
- 0 Post(s)
Ik snap het probleem niet bij een tussentabel... Correct me if im wrong
BLOG: http://blog.voltje.be/
DESKTOP: AMD Phenom x4 925 / ASUS Mobo / ATI RADEON HD5770 1GB DDR5 / 4GB DDR3 / 1x 24" Full HD Samsung/ Logitech G9x / QPad Lowsense / Logitech Illuminated !
LAPTOP: Lenovo T510 / Intel i5 @ 2.40Ghz / 8GB Ram / 120GB SSD
WOW CHAR: Averlena, Protection Paladin @ Talnivarrno votes
-
16-08-2011, 15:45 #29
De functie van die tabel is net om die veel-op-veel relatie voor te stellen.
Het gaat hier over data, niet over objecten of klassen. Er moet(/mag) geen gedrag(/nut/betekenis) gekoppeld zijn aan je entiteiten.no votes
-
16-08-2011, 18:08 #30Member
- Registered
- 23/11/03
- Location
- Landeurp
- Posts
- 1,791
- iTrader
- 0
- Mentioned
- 0 Post(s)
- Reputation
- 10/17
Die man heeft gelijk. Met een tussentabel zet je gewoon een veel-op-veelrelatie om naar twee één-op-veelrelaties en dat is de enige juiste manier. Een tussentabel hoeft geen enkele betekenis te hebben in je domain model (je gaat er met andere woorden geen klasse van maken) maar je moet ze natuurlijk wel betrekken in je queries.
no votes

Referral: 