Archief - Ontwerpmethode voor software (C#)

Hey,

Ik ben van zinnens de komende dagen te beginnen aan een "eenvoudig" programma om aan klant-, product- en aankoopbeheer te doen.

Gekozen taal is C# (heeft mijn voorkeur) maar nu vroeg ik mij af wat de beste ontwerpmethode zou zijn? Als omgeving gebruik ik visual studio, maar zal ik dan best gewoon Object georiënteerd (met klassen) werken? of zijn er andere ontwerpmethodes die voor dergelijk werk interessanter zijn?

(ps. ik heb al dergelijke programma's gemaakt maar dat was met VB en via een bepaalde ontwerpmethode die op school aangeleerd werd maar toch verouderd is voor zover ik weet)

Het programma zal tevens ook van een simpele database (sql) gebruik maken.


Moesten er nog vragen komen zal ik van dit topic gebruik maken.

Met vriendelijke groet,


Jeroen

Zowiso altijd voor object georiënteerd gaan. En ontwerp patronen zijn bepaalde technieken om zaken efficiënter,properder,... te schrijven in een object georiënteerde taal.

Maar aangezien je nog niet zoveel ervaring hebt met oo, kan je volgens mij gewoon best eerst wat bijleren en er dan pas aan beginnen.

hey , bedankt voor je snelle antwoord

ik had het niet over patterns (singleton etc. hebben we tijdens de lessen allemaal doorgenomen)

ik bedoel dat je bvb in plaats van met enkel klassen te werken ook kan werken met onderverdeling in verschillende lagen (BLL, DAL, presentation,..., je werkt dan ook nog steeds met klassen maar het is toch wat anders dan enkel en alleen klassen als onderverdeling)

Ik ben niet nieuw in de programmeer wereld (4j) maar vraag me gewoon af of er geen nieuwe state of the art zaken zijn waarop ik zou moeten letten/waarvan ik gebruik kan maken.

zoals ik ook reeds vermeld kan ik de software die ik wil schrijven, schrijven met de kennis die ik heb (heb al gelijkaardige complexere zaken(applicaties/webtoepassingen) moeten maken).

mijn excuses voor het wekken van een verkeerde indruk

bedankt

MVC is wel hot tegenwoordig.

Waarom wil je zo iets schrijven? er bestaan tegenwoordig elvendertig gratis CRM, ERP enzo systemen. de een al wat groter dan de andere.

Als het voor de fun is en om te oefenen, dan go for it
Als het effectief om te gebruiken is in een productie omgeving, kijk je best naar een bestaande.

Ik zou me eerder afvragen welke databasetechnologie en ORM je wil gaan gebruiken. Uiteindelijk zal complexiteit van code hier nihiel zijn en zal je vooral database acties doen.

Maar zoals passero al aangeeft, er zijn reeds zoveel frameworks die véél meer doen dan jij ooit zal kunnen programmeren gedurende je hele carrière. Ik denk maar bv als eerste aan SAP, maar er zijn tientallen andere.

Wel ge hebt natuurlijk zo'n dingen als DDD (Domain Driven Design) en wat tegenwoordig ook hip is is CQRS (Command and Query Responsibility Segregation) gewoon eens wat presentaties dervan volgen check: Greg Young, Udi Dahan enz enz

Dat zijn de manieren voor "Complexe" applicaties, dus zeker vrij overbodig voor een "eenvoudig" programma.

Voor simpele programmas gewoon dus uw DAL maken kijken als ge een BL maakt, al dan niet WCF nodig voor apps om te communiceren met BL, apps -> Winforms of WPF, asp.net of SL of JQuery / ajax, ....

Nuja WPF/Silverlight keuze hangt af van uw requirements die ik niet ken

voor ORM dit gebruiken -> Data.Linq - Business Logic Toolkit for .NET

U zeker niet inlaten met brol als Entity Framework of nHibernate

Waarom zou je uw project niet scheiden in "DAL, BL" etc ?
Alles in 1 project stoppen is toch ook al lang verouderd ? (tenzij in te verantwoorde gevallen)

't is inderdaad zoals cycloon zegt: Uw code zal niet veel voor stellen, het meeste werk zal hem zitten in de database transacties.

Alleszinds succes !

@Moto: Waarom zijn Entity Framework en nHibernate zo slecht?

@Moto: Waarom zijn Entity Framework en nHibernate zo slecht?

Klik om te vergroten...

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

'k gebruik het zelf niet, maar k dacht dat het goed was vandaar

Thanks !

Gebruik jij dan Linq2Sql ?

ik gebruik al 4 jaar ofzo -> Data.Linq - Business Logic Toolkit for .NET

zelfde ongeveer als Linq2Sql maar dan naar 12 db's
Zeer lage abstractie, zeer kleine learning curve (1 dag als ge Linq kent) en bijna geen leaks.

interessant moto ^^

nameless zei:

Zowiso altijd voor object georiënteerd gaan.

Klik om te vergroten...

Wat een gezonde ingesteldheid voor een software developer.

Als we het hier toch nog wat verder gaan hebben over databanken dan wil ik even het balletje opgooien voor objectdatabanken (ook wel post-relationele databanken genoemd). Het is een beetje jammer dat daar relatief weinig aandacht aan geschonken wordt. Veel grote bedrijven zijn nu eenmaal opgegroeid met relationele databanken en het onderwijs kent jammer genoeg ook nog niet veel anders. Het kan zeker de moeite lonen om ook eens in contact te komen met andere types databanken, veel relationele databanken beginnen ook steeds meer de features van post-relationele databanken na te bootsen. Je kan dan het volledige ORM gebeuren zonder problemen overboord gooien.

Hey,

Zeer leuk dat er veel reactie is, zelf heb ik al wel met het entity framework gewerkt en met jquery, maar het is zoals enkelen hier al aanhalen; het programma gaat zeer "simpel" zijn (zo goed als enkel persistente klasses (ze zullen objecten uit de databank weerspiegelen), het zal vooral draaien rond de transacties met de databanken welke eveneens heel simpel gaan blijven (misschien nog wat grafieken hier en daar maar dat is normaal ook niet het zotste programmeerwerk)...

Hierbij dan gelijk het antwoord op de vraag "waarom geen SAP/ERP...", het gaat echt heel basic zijn en op die manier wil ik het ook geheel gebruiksvriendelijk maken (heb zelf al ERP ervaringen en daar komt vaak toch ook wat uitleg bij kijken) en het is dus "te simpel" om er een SAP/ERP voor te gaan gebruiken en dat te configureren.. tevens is het voor familie en zou het dus handig zijn moestek het zelf hebben geschreven aangezien ik verwacht dat er geregeld iets extra/aanpassinge gevraagd zal worden... de grootste reden is dat ik het als vrije tijd / oefen project wil doen (het is zomer en zou zeker geen kwaad kunnen om ook tijdens deze periode wat te programmeren)...

Ben van plan er een dezer dagen (zeker volgende week) aan te beginnen, ik zal iedereen geupdate houden en ik ga ook enkele zaken die hier gepost werden bekijken (zoals die data.linq etc.) en indien er vragen bij me opkomen zal ik die hier posten

cycloon: ik heb zelf enkel ervaring met relationele databanken en ken dus zeer weinig van objectdatabanken (is vermeld geweest), heb je toevallig goede informatiebronnen (sites) hierover? lijkt me wel interessant om te gebruiken (aangezien de OO lijn doortrekken naar de databank wel interessanter is dan problemen te omzeilen (als een veel op veel relatie en dergelijke)



edit:

passero zei:

MVC is wel hot tegenwoordig.

Waarom wil je zo iets schrijven? er bestaan tegenwoordig elvendertig gratis CRM, ERP enzo systemen. de een al wat groter dan de andere.

Als het voor de fun is en om te oefenen, dan go for it
Als het effectief om te gebruiken is in een productie omgeving, kijk je best naar een bestaande.

Klik om te vergroten...

MVC heb ik pas gebruikt voor een grote webtoepassing samen met het entityframework ging dit zeer vlot, alleen heb ik echter de indruk dat dat meer naar webtoepassingen neigt?




nog eens bedankt voor de reacties! !!

groeten,

Jeroen

Moto zei:

voor ORM dit gebruiken -> Data.Linq - Business Logic Toolkit for .NET

U zeker niet inlaten met brol als Entity Framework of nHibernate

Klik om te vergroten...

Ik weet ondertussen wel al dat jij hier een grote fan van bent, maar zomaar even beweren dat hij zich niet moet inlaten met iets anders is wel kort door de bocht. Als 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. 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.

jer0nim07 zei:

cycloon: ik heb zelf enkel ervaring met relationele databanken en ken dus zeer weinig van objectdatabanken (is vermeld geweest), heb je toevallig goede informatiebronnen (sites) hierover? lijkt me wel interessant om te gebruiken (aangezien de OO lijn doortrekken naar de databank wel interessanter is dan problemen te omzeilen (als een veel op veel relatie en dergelijke)

Klik om te vergroten...

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.

Tyfius zei:

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.

Klik om te vergroten...

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.

Cycloon zei:

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.

Klik om te vergroten...

Dat is zeker waar. Het hangt vooral af van je eigen noden. Wat wil je bereiken, hoe wil je het bereiken en wanneer moet je het bereiken.

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 - 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?

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.

Als 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.

Klik om te vergroten...

idd NoSql document databases

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.

Klik om te vergroten...

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