Archief - Ontwerpmethode voor software (C#)

Moto zei:

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.

Klik om te vergroten...

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.

Moto zei:

Zaken moeten niet goed werken voor U, maar voor de gebruiker. "Toch wel goed werkt" is in mijn ogen niet goed genoeg

Klik om te vergroten...

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.

Moto zei:

Zeer grote Leaky abstractions met veel te grote learning curve, totaal geen ROI of ge moet als job constant kleine tijdelijke programmakes maken

ORM is an anti-pattern | Seldo.Com Blog
Interoperability Happens - The Vietnam of Computer Science

Klik om te vergroten...

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.

Moto zei:

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.

Zaken moeten niet goed werken voor U, maar voor de gebruiker. "Toch wel goed werkt" is in mijn ogen niet goed genoeg

Klik om te vergroten...

Als ge niet weet hoe 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

Emerxill zei:

Als ge niet weet hoe 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

Klik om te vergroten...

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.

Cheshire Cat zei:

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.

Klik om te vergroten...

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

jer0nim07 zei:

maar als het dan een gewone relationele databank wordt zit ik nog wel met dat relatie probleem dat ik in mijn vorige post vermeldde ?

Klik om te vergroten...

Waarom zouden veel-op-veelrelaties een probleem zijn?

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)

Ik snap het probleem niet bij een tussentabel... Correct me if im wrong

jer0nim07 zei:

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)

Klik om te vergroten...

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.

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.

En dat is net wat een objectdatabank wel kan vermijden. In een relationele databank zit er jammer genoeg niks anders op

forloRn_ zei:

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.

Klik om te vergroten...

dat is wat ik zei, maar het zou zowiezo beter zijn dat die tabel wel een betekenis zou hebben/nuttige informatie bevat (aldus Craig Larman en mijn leerkracht software engineering ) (niet dat dat in mijn geval zoveel uitmaakt, maar tabellen met betekenis zijn altijd beter dan tabellen zonder, hetzelfde geld voor primary keys, een PK met betekenis is ook beter, hoewel iedereen vaak surrogaat sleutels gebruikt)

--> zo werd het mij op school aangeleerd , de praktijk is wellicht anders

Als iemand zegt dat iets altijd zo is, zijn ze altijd volledig verkeerd (wat betreft software development).

Ik zou voor WPF c# gaan met MVVM aparte model laag (dus je db linken aan dit model) dan je viewmodel om te fitten op je view. Werkt heel goed, ens je het gewent bent wil je niets meer anders! (lijkt beetje op MVC) ...

check : patterns & practices: Prism