[C#] Desktop applicatie fundering / begin

[Rolandow]

Mijn vraag is erg algemeen en/of groots, dat realiseer ik me, maar ik hoop toch op wat waardevolle reactie's. Even een korte probleemomschrijving. Er is bij een bedrijf een uitgebreid ERP pakket geprogrammeerd. Dit voldoet prima, alleen is het platform verouderd (denk aan Filemaker / DOS omgeving-achtige legacy). Na enige tijd speuren denken we dat C# met een relationele database een goede vervanger zou kunnen zijn.

We hebben hier zelf programmeurs dit dit willen gaan maken, alleen het begin is toch wat lastiger dan gedacht. Want waar begin je? Er zijn zoveel libraries en technieken dat ik persoonlijk, als 1 van de programmeurs, door de bomen het bos niet meer zie. Ik ben er van overtuigd dat we de goede weg zijn in geslagen, maar we hebben momenteel te weinig ervaring in C# om te kunnen beoordelen wat een goede start zou zijn.

We denken dat WPF een goede keuze zou zijn omdat er (nu nog) windows 7 machine's draaien, maar deze techniek toch moderner is dan WinForms, zodat eventuele transitie naar UWP straks ook beter gaat.

Persoonlijk heb ik best wat ervaring met OO, database modelleren en het toepassen van design patterns. Maar voor deze nieuwe applicatie is de vraag; welke design patterns zijn de beste, zodat we later niet tegen limieten aanlopen. En dit geldt ook voor de libraries; welke zijn er (voor ons) het beste?

Ik (of we, eigenlijk) zou heel graag eens sparren met een andere ontwikkelaar op C# gebied, gewoon van programmeur tot programmeur, techneut tot techneut. Je zou het consultancy kunnen noemen, maar het vervelende is dat de meeste consultancy bedrijven je een product proberen te verkopen, of een poppetje zo lang mogelijk weg willen zetten. Er is dus wel budget, maar de focus moet liggen dat we het zelf willen bouwen, en dus eigenlijk even een zetje nodig hebben in de juiste richting.

Vandaar dat ik hier terecht kwam; omdat ik telkens op zoek ben naar hoe ik iets voor elkaar krijg, en dan telkens weer denk: is dit wel de juiste richting?

We zitten dus nu op het spoor van een WPF appilcatie, omdat het een desktop applicatie moet worden. Pas in de (verre?) toekomst zullen delen van de applicatie ook op andere devices beschikbaar komen.

Momenteel ben ik aan het stoeien met Caliburn.Micro als MVVM framework, en Autofac als DI container. Onze applicatie bestaat uit vele deel applicaties. Denk aan relatie beheer, project management, voorraad beheer, etc. etc.

Een praktisch voorbeeld waar ik nu mee zit is (heel simpel); hoe open ik een nieuw scherm vanuit mijn ShellViewModel waarbij ik de mogelijkheden van Autofac dus kan benutten?

Het is nu al een heel verhaal geworden, dus ik laat het hier nu even bij om reactie's af te wachten. Ben zeer benieuwd of er mensen zin hebben (en tijd hebben) om te helpen.

Alvast bedankt voor de aandacht tot zover!

[Gertjuhjan]

Wat is de reden dat deze software een desktop applicatie moet worden?

Als je toch opnieuw begint, dan zou ik er een webapplicatie van maken.

Bijvoorbeeld:
ASP.NET Core
Entity Framework Core
Angular als frontend

Backend met CQRS opzetten

[ Voor 26% gewijzigd door Gertjuhjan op 05-02-2019 11:27 ]

[Marber]

Ik zou op zijn minst een scheiding aanleggen tussen de front en backend (op basis van services, in welke vorm dan ook). Op die manier kan je later een stuk eenvoudiger een tweede (webbased) frontend bouwen, zonder allelei business rules te moeten inbakken

[418O2]

Ik zou ook gewoon een webapplicatie bouwen. Dan zit je niet vast aan windows, is toekomstbestendiger en waarschijnlijk kan je er meer resources voor vinden.

[Styxxy]

Rolandow schreef op dinsdag 5 februari 2019 @ 11:21:
Mijn vraag is erg algemeen en/of groots, dat realiseer ik me, maar ik hoop toch op wat waardevolle reactie's. Even een korte probleemomschrijving. Er is bij een bedrijf een uitgebreid ERP pakket geprogrammeerd. Dit voldoet prima, alleen is het platform verouderd (denk aan Filemaker / DOS omgeving-achtige legacy). Na enige tijd speuren denken we dat C# met een relationele database een goede vervanger zou kunnen zijn.
[...]

Je hebt een eigen ERP pakket gebouwd...
In plaats van opnieuw veel geld te investeren in het bouwen van (scratch) een nieuwe toepassing; heb je al eens overwogen om een bestaand ERP pakket te gebruiken?

Doet me wat denken aan "not invented here".

[Rolandow]

En web applicatie is niet wenselijk, omdat er schermen zijn die met elkaar communiceren. Bovendien kun je in een browser minder makkelijker zoveel informatie kwijt als in een desktop applicatie. Voor deze job was ik jarenlang fullstack web developer, dus als het geschikt zou zijn zou ik hier ook liever voor kiezen.

Het opdelen in services is inderdaad een vaker geopperd idee. Maar als de Entity Framework code in een shared library komt, dan leek het me sowieso niet zo lastig om hier op een later moment een service voor te maken. De desktop applicaties kunnen deze libraries dan direct gebruiken, zodat er geen overhead is bij het omzetten van/naar json.

We hebben inderdaad gekeken naar bestaande ERP pakketten. Buiten het feit dat deze ook niet goedkoop zijn, hebben deze niet de maatwerk erin zitten die we nu hebben. Qua kosten zal het dus niet veel uit maken. We hebben ook naar andere bedrijven in ons werkgebied gekeken die voor een bestaand pakket hebben gekozen, en dat brengt weer andere problemen met zich mee.

[RoofTurkey]

Het is erg lastig om vooraf te bepalen wat je moet doen bij een dergelijk project. Doet ook erg denken aan ouderwetse planningsmethodieken als waterval. Kijk eerst even wat nodig is (maak een backlog van epics), ga daarna op basis van prioriteit een volgorde hierin maken (neem hier vooral ook de rest van het bedrijf die met de software te maken krijgt mee). Daarna kun je voor deze grotere brokken werk weer kleinere hapklare taakjes maken die (zoveel als mogelijk) los van elkaar kunnen worden opgepakt. Dit zorgt er meteen al voor dat je meer in gescheiden services denkt. Als laatste ga je samen met het team deze losse hapklare taken oppakken en zorg je ervoor dat je grip houdt door af en toe (bijvoorbeeld iedere ochtend) even met het team te bespreken hoe het gaat, wat de uitdagingen zijn, wie wie kan helpen, etc. Dat is een beetje agile werken in een notendop. Pas het vooral links en rechts aan naar jullie behoefte, maar probeer wel op die manier te werken. Zeker in zo'n groot en onzeker project.

Zorg ook vooral voor zoveel mogelijk releases (CI/CD), van zowel automatische tests als acceptatie/productie omgevingen. Zo kun je snel zien wat wel/niet werkt en ook makkelijker demo'en aan de non-developers.

Mocht je dan tegen problemen aanlopen dan kun je ook veel concretere vragen stellen, nu is het vrijwel onmogelijk om je te helpen met bijvoorbeeld een keuze voor design pattern. Dit kan voor ieder losse stukje bijvoorbeeld weer anders zijn.

[Khallouki]

Voordat je uberhaupt begint met het bepalen van de techniek zou ik eerst goed met de business zitten en vragen wat ze precies willen hebben. Waar lopen ze tegenaan? Wat willen ze beter zien? Adviseer ze daarin en zet de eisen om in functionele eisen. Ontwerp één of meerdere datamodellen, hoe gaat je architectuur eruit zien? Kijk daarna pas welke techniek je wilt gebruiken (web, desktop, asp, php, java).

Ik zal daar eerst mee beginnen.

[Rolandow]

Planning is inderdaad een belangrijk onderdeel. We hebben gelukkig een applicatie die eigenlijk best goed functioneert, dus aan de hand daarvan kunnen we goed ons doel bepalen.

Ik heb ook wel hele specifieke vragen qua c#, waarvan ik er al eentje noemde, maar die wilde ik niet persé nu direct al stellen. De ene haakt in op de ander, etc. Het gaat er meer om of er iemand bereid is, zin in heeft, om hier samen naar te kijken. Bijvoorbeeld in een gesprek, een mail conversatie, of door langs te komen bij ons op kantoor.

Want uiteindelijk komt het er allemaal op neer dat het nog even ontbreekt aan de structuur.

Een applicatie bestaat natuurlijk uit vele onderdelen, en voor al die onderdelen zijn er meerdere methoden om dat specifieke onderdeel te maken. Zoals je bij PHP waarschijnlijk uitkomt bij Symfony of Laravel, hoe zit dat bij C#?

Er is dus al wat voorwerk gedaan, en dat kunnen we ook goed genoeg zelf denk ik. We hebben al een data model. We hebben ook al bepaald welke techniek we willen gebruiken: een desktop applicatie in C# dus.

De oplossing is hier in dit topic niet te geven denk ik; dat was dus ook niet de bedoeling. De bedoeling was om te polsen of hier techneuten zitten die dit willen. En om op deze manier de account managers en sales mensen te omzeilen.

Bedankt voor de reactie's zo ver!

[Argantonis]

Ik vind de keuze voor C# terwijl niemand daar echt ervaring in heeft daar wel apart. Als je zelf al fullstack developer bent, waarom dan idd geen webtechnologie? Het argument dat schermen met elkaar communiceren vind ik niet zo heel sterk. Webtechnologie betekent niet per definitie dat je backend geen state mag bijhouden. Dat maakt dingen natuurlijk een stuk makkelijker qua scaling, maar je hebt altijd wel een nadeel ergens, en is ook niet zo relevant voor een applicatie die eigenlijk functioneert als desktop-applicatie. Je kan dus prima een sessie bijhouden op de backend met daarin scherm state. Desnoods draai je de instanties in beginsel lokaal. Dan blijf je in ieder geval wel bij de technologie die je kent. Maar dat is wel een stuk makkelijker omzetten later als je wel ook een mobiele app of web-applicatie van (een deel van) de functionaliteit wil hebben. Dat het ook op mobiel werkt is toch wel een redelijke standaard nu.

Als je dat niet wilt doen dan zou ik op z'n minst een C# ontwikkelaar met ervaring aannemen. Als ik het goed begrijp kent niemand daar C# echt goed, dat ga je niet oplossen met een paar consultancy sessies.
Als je baas het goed vindt dat je in zijn of haar tijd met een heel team een hele nieuwe taal en alle bijbehorende frameworks en libraries gaat uitzoeken dan heb je geluk, maar ik zou dat niet helemaal fair vinden naar je baas toe.

[ Voor 9% gewijzigd door Argantonis op 05-02-2019 13:21 ]

[Rolandow]

Mijn achtergrond is web developer, maar die van mijn collega niet. Maar zoals gezegd; de informatie die we nu in staat zijn te tonen, gaat niet zo goed in een web applicatie passen. Het is bovendien ook niet nodig, geen wens.

De baas vindt het goed inderdaad, bedankt voor het medeleven, en we communiceren daar ook gewoon eerlijk over.

Ik merk zelf dat het me niet snel genoeg gaat, en dat ik gewoon eens eerlijk en open zou willen sparren met iemand die 'in het veld' dagelijks applicaties bouwt, het liefst met de laatste technieken. Winforms zou bijvoorbeeld prima kunnen werken, maar als ik het zo lees heeft WPF toch wel de voorkeur.

Voor een ander project werk ik wel met C# (een service). Een nieuwe taal leren an sich lijkt me niet zo'n obstakel. Het gaat er meer om; wat is de juiste mix? Ga je voor Symfony, dan gebruik je Doctrine en Twig waarschijnlijk... dat werkt gewoon goed samen. Maar al die opgebouwde taal-specifieke kennis heb ik nu even niet voor handen.

Het is geen probleem om dat de komende tijd te gaan leren, maar ik probeer te voorkomen dat ik me iets ga aanleren waarvan de C# community eigenlijk op voorhand al weet dat er teveel beperkingen zijn.

[Gertjuhjan]

Rolandow schreef op dinsdag 5 februari 2019 @ 13:38:
Ik merk zelf dat het me niet snel genoeg gaat, en dat ik gewoon eens eerlijk en open zou willen sparren met iemand die 'in het veld' dagelijks applicaties bouwt, het liefst met de laatste technieken. Winforms zou bijvoorbeeld prima kunnen werken, maar als ik het zo lees heeft WPF toch wel de voorkeur.

WPF en "de laatste technieken" worden meestal niet in één zin genoemd. Omdat WPF gewoon aan de oude kant is. (Maar wel nog de beste manier voor het ontwikkelen van win32 desktop applicaties).

[Rolandow]

Klopt, WPF is niet het allernieuwst. Maar toen ik op zoek was naar trainingen valt het op dat een hoop programma's nog verder achterlopen.

Redelijk nieuwe technieken was wellicht een betere benaming :-)

[anboni]

Styxxy schreef op dinsdag 5 februari 2019 @ 11:42:
[...]
In plaats van opnieuw veel geld te investeren in het bouwen van (scratch) een nieuwe toepassing; heb je al eens overwogen om een bestaand ERP pakket te gebruiken?

Ja, dat was hier ook het advies van een duurbetaalde consultancy toko: stuur het oude (in vb6 gebouwde) ERP systeem met pensioen en implementeer een off-the-shelf ERP pakket. Inmiddels zijn we 6 jaar en 1.5miljoen euro verder en hebben we een ERP pakket wat in de basis ongeveer voldoet maar wat nog niet de helft van de features biedt die het inhuis ontwikkelde systeem bood...

[Rolandow]

Bedankt anboni, dat geeft de burger moed ;-)

[Arie-]

Ik kan je zelf niet direct helpen, maar ken wel een bedrijf waar ze zelf het ERP in ontwikkeling hebben met onderdelen als:

• koppeling met toegang en urenregistratie via Paxton hardware.
• aansturing productie vanuit CAD (weet zo niet meer welke applicatie, was geen AutoCAD, maar een alternatief)
• daar gebruiken ze visual studio en zijn ze door de jaren heen van Visual Basic naar nu C# gegaan.

Ze zijn er volgens mij mega tevreden over, voornamelijk om de bijzonder korte lijntjes Ze verhuren de software tegenwoordig ok. Een anecdote die ik me kan herinneren is dat de leverancier van de CAD software toch wel wilde weten wat er daar op kantoor gaande was omdat er zoveel burgreports gesubmit werden. Ik ga geen contactgegevens rondstrooien zonder toestemming, mocht je meer willen weten dan kan ik evt. vragen of ze daar trek hebben in een adviesklus. Ik weet niet of ze daar aan doen, er tijd voor hebben en wat hun tarieven zijn.

Voor wat het waard is: zelf ben ik in een klein software bedrijf gerold waar al wat zaken aanwezig waren gebaseerd op Delphi. Voor het maken van simpele formulieren: heerlijk je klikt 't zo in elkaar. Met oog op de toekomst proberen we wel nieuwe functionaliteiten op andere manieren te verwezenlijken en wat weg te blijven van Delphi.

[Hydra]

Rolandow schreef op dinsdag 5 februari 2019 @ 14:55:
Bedankt anboni, dat geeft de burger moed ;-)

Omdat dat precies is wat je wil horen?

[Rolandow]

Arie- schreef op dinsdag 5 februari 2019 @ 15:08:
Ik kan je zelf niet direct helpen, maar ken wel een bedrijf waar ze zelf het ERP in ontwikkeling hebben met onderdelen als:

• koppeling met toegang en urenregistratie via Paxton hardware.
• aansturing productie vanuit CAD (weet zo niet meer welke applicatie, was geen AutoCAD, maar een alternatief)
• daar gebruiken ze visual studio en zijn ze door de jaren heen van Visual Basic naar nu C# gegaan.

Ze zijn er volgens mij mega tevreden over, voornamelijk om de bijzonder korte lijntjes Ze verhuren de software tegenwoordig ok. Een anecdote die ik me kan herinneren is dat de leverancier van de CAD software toch wel wilde weten wat er daar op kantoor gaande was omdat er zoveel burgreports gesubmit werden. Ik ga geen contactgegevens rondstrooien zonder toestemming, mocht je meer willen weten dan kan ik evt. vragen of ze daar trek hebben in een adviesklus. Ik weet niet of ze daar aan doen, er tijd voor hebben en wat hun tarieven zijn.

Voor wat het waard is: zelf ben ik in een klein software bedrijf gerold waar al wat zaken aanwezig waren gebaseerd op Delphi. Voor het maken van simpele formulieren: heerlijk je klikt 't zo in elkaar. Met oog op de toekomst proberen we wel nieuwe functionaliteiten op andere manieren te verwezenlijken en wat weg te blijven van Delphi.

Bedankt voor je reactie! In onze branche zijn een hoop klanten en concollega's ook best onder de indruk. Het werkt eigenlijk ook wel goed. Als het met z'n tijd was mee gegaan dan zouden we nooit overstappen.

Delphi hebben we ook naar gekeken, maar de community is toch een stuk kleiner. Bovendien programmeert een heel andere afdeling van ons ook in C en C++, dus er is al meer C kennis aanwezig. Bovendien vind ik C# eigenlijk ook wel heel mooi, qua programmeertaal.

We hebben uiteindelijk voor C# gekozen omdat ik denk dat daar meer support voor te vinden is. En alhoewel ik geen fanboy van Microsoft ben; het is wel een solide bedrijf. Ik durf wel te stellen dat C# nog wel een tijdje zal blijven bestaan ;-).

[Gertjuhjan]

Rolandow schreef op dinsdag 5 februari 2019 @ 15:13:
[...]


Bedankt voor je reactie! In onze branche zijn een hoop klanten en concollega's ook best onder de indruk. Het werkt eigenlijk ook wel goed. Als het met z'n tijd was mee gegaan dan zouden we nooit overstappen.

Delphi hebben we ook naar gekeken, maar de community is toch een stuk kleiner. Bovendien programmeert een heel andere afdeling van ons ook in C en C++, dus er is al meer C kennis aanwezig. Bovendien vind ik C# eigenlijk ook wel heel mooi, qua programmeertaal.

We hebben uiteindelijk voor C# gekozen omdat ik denk dat daar meer support voor te vinden is. En alhoewel ik geen fanboy van Microsoft ben; het is wel een solide bedrijf. Ik durf wel te stellen dat C# nog wel een tijdje zal blijven bestaan ;-).

Ik zou niet beginnen aan Delphi. Ik ben voor verschillende projecten ingevlogen om software naar het .NET platform te brengen omdat ze Delphi ontwikkelaars niet meer konden vinden.

[Rolandow]

Hydra schreef op dinsdag 5 februari 2019 @ 15:10:
[...]


Omdat dat precies is wat je wil horen?

Nou nee, meer omdat er meer mensen zijn die deze gedachtegang volgen.

Met projecten van deze omvang is het altijd koffiedik kijken denk ik. Er zijn veel voorbeelden van grote software fabrikanten die steeds meer geld gaan vragen voor maatwerk, maar er zijn ook verhalen van bedrijven die alles zelf doen en vervolgens met een systeem zitten dat incompatibel of slecht onderhoudbaar is.

[DJMaze]

Rolandow schreef op dinsdag 5 februari 2019 @ 12:15:
En web applicatie is niet wenselijk, omdat er schermen zijn die met elkaar communiceren. Bovendien kun je in een browser minder makkelijker zoveel informatie kwijt als in een desktop applicatie. Voor deze job was ik jarenlang fullstack web developer, dus als het geschikt zou zijn zou ik hier ook liever voor kiezen.

Raar, ik kan prima een web applicatie maken waarbij meerdere schermen met elkaar communiceren, en ik kan in een browser heel makkelijk veel meer informatie kwijt dan een gewone desktop applicatie.

Simpelste voorbeeld is natuurlijk een WYSIWYG die in een object/iframe draait en dus communiceert tussen twee "schermen"...

Rolandow schreef op dinsdag 5 februari 2019 @ 15:13:
Microsoft is wel een solide bedrijf. Ik durf wel te stellen dat C# nog wel een tijdje zal blijven bestaan ;-).

Dat dachten we ook van Silverlight en wat andere technieken...

[ Voor 28% gewijzigd door DJMaze op 05-02-2019 16:19 ]

[Styxxy]

anboni schreef op dinsdag 5 februari 2019 @ 14:53:
[...]
Ja, dat was hier ook het advies van een duurbetaalde consultancy toko: stuur het oude (in vb6 gebouwde) ERP systeem met pensioen en implementeer een off-the-shelf ERP pakket. Inmiddels zijn we 6 jaar en 1.5miljoen euro verder en hebben we een ERP pakket wat in de basis ongeveer voldoet maar wat nog niet de helft van de features biedt die het inhuis ontwikkelde systeem bood...

Waarschijnlijk omdat je het ERP pakket exact hetzelfde probeert te maken als het eigen ontwikkelde platform. Dit is nooit wenselijk. Je moet een pakket kiezen dat je qua filosofie ziet zitten, en deze filosofie ook adapteren. Een bestaand product proberen om te vormen naar exact hetzelfde dat je al had, gaat inderdaad veel geld kosten (en waarschijnlijk falen, of alleszins niet geweldig goed werken). "As is" conversies zijn weinig nuttig.

Note: ik ben geen consultant bij een toko; ik werk bij een (groot) bedrijf waarbij we deze challenge / oefening ook aan het doen zijn.

Rolandow schreef op dinsdag 5 februari 2019 @ 15:17:
[...]
Met projecten van deze omvang is het altijd koffiedik kijken denk ik. Er zijn veel voorbeelden van grote software fabrikanten die steeds meer geld gaan vragen voor maatwerk, maar er zijn ook verhalen van bedrijven die alles zelf doen en vervolgens met een systeem zitten dat incompatibel of slecht onderhoudbaar is.

Zie hierboven. Probeer niet met gigantisch veel maatwerk een bestaand product exact te maken zoals het vorige product. Hou dan het oude product as-is. Een nieuw jasje voor de "fun of it", biedt geen meerwaarde naar de business. Je moet verandering met meerwaarde doen; en die meerwaarde ga je creëren ook door bestaande processen te reviseren en aan te passen. Pas je zelf ook (deels) aan aan de workflow van het pakket waarvoor je kiest.

[ Voor 28% gewijzigd door Styxxy op 05-02-2019 16:40 ]

[Rolandow]

Styxxy schreef op dinsdag 5 februari 2019 @ 16:38:
[...]

Pas je zelf ook (deels) aan aan de workflow van het pakket waarvoor je kiest.

Dit is nu precies wat er de afgelopen tijd niet is gedaan, en waar we ook veel profijt van hebben. De workflow die de afgelopen decennia is ontwikkeld werkt voor ons juist erg goed.

Het gaat dan ook niet om een nieuw jasje for the fun of it. Het gaat erom dat het pakket nog 20 jaar mee moet kunnen, en in zijn huidige vorm zou dat in de toekomst wel eens lastig kunnen worden. Daarom investeren we nu in een verbetering.

De keuze voor een bestaand pakket keur ik niet af, ik snap heel goed dat een hoop bedrijven hiervoor kiezen. Echter is onze mening dat, in ons werkveld, ons pakket eigenlijk best goed in elkaar zit. Daarnaast zijn we reuze flexibel wat betreft aanpassingen.

Het is alleen jammer dat de achterliggende techniek te wensen over laat. Zowel de programmeertaal als de database engine zijn achterhaald. Daarom vormt dit een gevaar voor de continuïteit van het pakket, en kiezen we ervoor om het truucje nogmaals te doen, alleen dan beter. Uiteraard zullen dan ook direct een aantal verbeteringen door te voeren zijn. Het oude product houden "as-is" zouden we inderdaad het liefst doen, maar het is de vraag of dit over 20 jaar nog haalbaar is. Vandaar dat we op tijd investeren in iets nieuws.

Ik betwijfel of er een heilige graal bestaat. Maar binnen de gemaakte keuze (voor ons dus C# desktop applicatie) zijn er wel ongetwijfeld best practices.

[YakuzA]

Als je het perse in een desktop applicatie compleet in .NET vorm wil gieten zul je ongetwijfeld uitkomen op een WPF front-end, die connect naar een Secure WCF service aan de achterkant die ergens op een server als (windows) service draait en de business logic afhandeld en het weer richting je database doormikt.

Dat is in principe gewoon het Multi-tier architecture vertaald naar je .NET toolbox.

Om te proberen al je Business logic in de presentation layer van je WPF te proppen lijkt me niet wenselijk in dit soort applicaties.

[Rolandow]

Yakuza, dat klinkt inderdaad goed. Dat zou ik nou graag eens uitwerken met iemand die er veel ervaring mee heeft. Gewoon een simpel scherm met een paar velden.

Maar dat de tools die daarvoor nodig zijn dus opgezet worden en het van voor tot achter werkt.

Het zou denk ik zoveel tijd schelen als je een goed voorbeeld hebt van waaruit je kunt werken. En als de toolchain eenmaal duidelijk is dan is het daarna een kwestie van daar steeds meer mee doen en beter in worden. Dat gaat wel lukken dan.

[Afvalzak]

Is het een idee om een groot software bedrijf met veel ervaring de basis op te laten zetten waarop jullie kunnen voortzetten, daar kunnen jullie verschrikkelijk veel van leren en je loopt niet tegen de, voor ervaren partijen bekende, valkuilen aan?

[BertS]

YakuzA schreef op dinsdag 5 februari 2019 @ 17:14:
Als je het perse in een desktop applicatie compleet in .NET vorm wil gieten zul je ongetwijfeld uitkomen op een WPF front-end, die connect naar een Secure WCF service aan de achterkant die ergens op een server als (windows) service draait en de business logic afhandeld en het weer richting je database doormikt.

Dat is in principe gewoon het Multi-tier architecture vertaald naar je .NET toolbox.

Om te proberen al je Business logic in de presentation layer van je WPF te proppen lijkt me niet wenselijk in dit soort applicaties.

Daar zit ook nog een tussenweg in denk ik. Je kunt je logica prima scheiden en in een eigen serviceassemblie (of meerdere) onderbrengen, zonder daarvoor een WCF-service en bijbehorende 'applicatieserver' op te tuigen. Dat maakt de leercurve wat minder steil, met een even prima resultaat.
En als je voor een fysiek gescheiden servicelaag wilt gaan, waarom dan geen WebAPI? Daar zit meer toekomst in dan in WCF.

Afvalzak schreef op dinsdag 5 februari 2019 @ 20:08:
Is het een idee om een groot software bedrijf met veel ervaring de basis op te laten zetten waarop jullie kunnen voortzetten, daar kunnen jullie verschrikkelijk veel van leren en je loopt niet tegen de, voor ervaren partijen bekende, valkuilen aan?

Waarom een groot softwarebedrijf? Er zijn zat zzp'ers of kleine bedrijfjes die hier ruime ervaring in hebben, een als ik het zo lees beter passen bij het bedrijf waar TS werkt.

[ Voor 20% gewijzigd door BertS op 05-02-2019 20:25 ]

[BugBoy]

Zelf een ERP pakket schrijven is bijna altijd een slecht idee. En als ik deze vragen allemaal zo bekijk, dan vraag ik me ernstig af of je hier wel aan moet beginnen. Tenzij jullie allemaal vrijwilligers zijn gaat zo'n zelfbouw oplossing echt serieus geld kosten. @anboni heeft al deze ervaring, maar hij mag zich troosten. Met hem zijn er velen die even dachten een ERP pakketje te maken...

Voor een Windows desktop applicatie lijkt WPF wellicht een voor de hand liggende keuze. Ik ben WPF-programmeur van het eerste uur (toen nog Avalon), maar ik zou er nu niet gauw meer voor kiezen. Het heeft een aantal grote nadelen:

• Het is Windows only en dus niet te gebruiken vanaf een mobiel apparaat. Dat wordt een steeds groter nadeel.
• Microsoft stopt vrijwel geen effort meer in WPF. Op wat HiDPI zaken na is er eigenlijk geen ontwikkeling meer. Het wordt nu naar .NET Core geporteerd, maar ik vraag mij af voor wie dat interessant is (het blijft Windows only).
• WPF is flexibel in zijn look & feel, maar erg rigide in architectuur. Het is erg lastig om goed gebruik te maken van zaken als Dependency Injection of asynchrone verwerking. Asynchrone commando's gaan nog wel, maar routed events wordt al een heel stuk lastiger.

Met een goed client-side framework (Angular, React, Vue, ...) is vrijwel hetzelfde te bereiken als je in WPF zou doen, maar dan wel cross-platform en (eventueel responsive) op mobiele apparaten. Als je echt meerdere schermen nodig hebt, dan zijn er ook andere oplossingen. Je kan met WebStorage gaan werken (als het op één PC moet blijven), maar anders is wellicht SignalR ook een optie.

Als ik jouw posts bekijk dan wil je in eerste instantie geen gebruik maken van client/server, maar een enkele applicatie die de database aanspreekt. Met meerdere instanties ga je geheid tegen locking issues aanlopen. Het feit dat je de data-access laag in een shared library zet maakt het niet dat je het later eenvoudig lostrekt. Dan krijg je te maken met state, serialization, ...

Om eerlijk te zijn denk ik dat jullie er echt te makkelijk over denken. De kans dat het management te hoge verwachtingen heeft die jullie niet waar gaan maken is levensgroot.

[BertS]

BugBoy schreef op dinsdag 5 februari 2019 @ 20:27:
Zelf een ERP pakket schrijven is bijna altijd een slecht idee. En als ik deze vragen allemaal zo bekijk, dan vraag ik me ernstig af of je hier wel aan moet beginnen. Tenzij jullie allemaal vrijwilligers zijn gaat zo'n zelfbouw oplossing echt serieus geld kosten. @anboni heeft al deze ervaring, maar hij mag zich troosten. Met hem zijn er velen die even dachten een ERP pakketje te maken...

Het lastige is: er zijn ook voorbeelden waar het wel een succes is geworden. Ik ken er meerdere waarbij het management zich heel goed realiseerde wat het betekent, en weloverwogen de keuze maakte voor zelf bouwen.
Er zitten gewoon heel veel kanten aan, waar over nagedacht moet zijn. Wat natuurlijk belangrijk is, om de angst die velen hier ventileren wat te relativeren, is dat omvang. Een ERP-pakket dat vermarkt moet worden heeft aanmerkelijk meer complexiteit in zich dan een interne applicatie die de eigen processen moet ondersteunen. Daarbij heeft het kansen en risico's. Soms ben je wendbaarder, en soms minder wendbaar. Het kan serieus geld kosten, maar kan ook goedkoper zijn.
Concreet voorbeeld: ik ben ooit betrokken geweest bij een situatie waar een eigen applicatie was gebouwd door een externe partij. Toen daar zo'n 2 ton in geïnvesteerd was, ontstond er een contact met een leverancier van een standaard oplossing voor die branche. Na een uurtje heen en weer praten vroeg die belangstellend naar de investering. Daarna gaf hij eerlijk aan dat hun oplossing voor die organisatie alleen al aan licenties pakweg een miljoen zou moeten kosten, waarbij er nog geen consultant over de vloer was geweest. En ja, die had uiteraard meer mogelijkheden op diverse vlakken. Interne uren kunnen we waarschijnlijk wel zo'n beetje wegstrepen.
Dit is niet bedoeld om te zeggen dat het altijd verstandig is, maar wel om een beetje te relativeren. Het hoeft niet altijd een slecht idee te zijn.

BugBoy schreef op dinsdag 5 februari 2019 @ 20:27:
Om eerlijk te zijn denk ik dat jullie er echt te makkelijk over denken. De kans dat het management te hoge verwachtingen heeft die jullie niet waar gaan maken is levensgroot.

Waar maak je uit op dat er te makkelijk over gedacht wordt? TS schrijft verder niet over het beslissingsproces?
Als men nu het ook intern heeft geautomatiseerd middels een applicatie/databaseplatform (a la Filemaker zoals wordt genoemd), dan is men er sowieso al aan gewend.


En dan wat meer ontopic:

BugBoy schreef op dinsdag 5 februari 2019 @ 20:27:
Met meerdere instanties ga je geheid tegen locking issues aanlopen.

Want?
Het is iets waar je je bewust van moet zijn. Maar als het nu via zo'n app/db-platform stabiel werkt, zal de concurrency niet dermate groot zijn dat hier erg grote risico's in zitten.


UI-technologie blijft een lastige. Windows specifiek, en moet op Windows 7 draaien, dan denk je aan WPF of Winforms. Beide met voordelen en nadelen. Weboriënted frameworks zijn een overweging, maar wellicht niet direct noodzakelijk.
Zelf ben ik meer ervaren in Winforms. Nadelen van WPF zijn hierboven genoemd. Zelf zou ik eigenlijk alleen voor WPF kiezen als er behoefte is om UI-design door iemand anders te laten doen. De situatie van TS (met twee ontwikkelaars in dienst van het bedrijf) wijst er meer op dat jullie dat zelf moeten doen. Dan denk ik dat je met Winforms productiever bent en beter/makkelijker een goede UX voor je gebruikers kunt realiseren.

Qua toekomstvastheid: gezien de keuze van Microsoft om zowel WPF als Winforms naar .NET Core te brengen, en de adoptie in het veld, zou het mij verrassen als Winforms eerder verdwijnt dan WPF.

[Afvalzak]

Het gehele winforms/WPF verhaal hoeft toch geen issue te zijn als je een server kant hebt die je met een API kan benaderen vanuit je client? Dan kan je over 5 jaar alsnog de webinterface maken mocht dat nodig zijn, of een uitgeklede mobiele versie.

[BertS]

Afvalzak schreef op dinsdag 5 februari 2019 @ 21:52:
Het gehele winforms/WPF verhaal hoeft toch geen issue te zijn als je een server kant hebt die je met een API kan benaderen vanuit je client? Dan kan je over 5 jaar alsnog de webinterface maken mocht dat nodig zijn, of een uitgeklede mobiele versie.

Niet qua maintenance nee.
Nu dus wel voor het opzetten.

[DJMaze]

Ook al ben ik het eens met BugBoy.
Ik denk dat we waarschijnlijk te groot denken.
Een bedrijf met zo'n 40 man personeel kan prima zelf een ERP maken en intern gebruiken zolang ze maar weten dat het op de zelfde manier 20 jaar houdbaar is zoals de huidige DOS/filemaker/whateffa variant.

Gewoon accepteren dat men over 5 jaar zegt dat het weer iets nieuws/hips moet zijn.

Ja, ik programmeer ook nog steeds in Delphi en C++ en dat werkt op Windows OS en GNU/Linux.
Voor tablets/mobiel/web gebruiken we wat anders en alles werkt prima samen met een Firebird DB i.s.m. db event listners

[anboni]

BugBoy schreef op dinsdag 5 februari 2019 @ 20:27:
Zelf een ERP pakket schrijven is bijna altijd een slecht idee. En als ik deze vragen allemaal zo bekijk, dan vraag ik me ernstig af of je hier wel aan moet beginnen. Tenzij jullie allemaal vrijwilligers zijn gaat zo'n zelfbouw oplossing echt serieus geld kosten. @anboni heeft al deze ervaring, maar hij mag zich troosten. Met hem zijn er velen die even dachten een ERP pakketje te maken...

Je hebt mijn post blijkbaar niet goed geinterpreteerd. We hadden een zelfbouw ding wat prima werkte. Nu hebben we een commercieel pakket waarmee we net aan de basisfunctionaliteit hebben, maar nog niet in de buurt komen van de functionaliteit die we voorheen hadden (en nog dagelijks missen)

[farlane]

In feite heb je je keuzes al gemaakt volgens mij (en volgens mij geen slechte) op basis van het type bedrijf waar je werkt, wat je denkt nodig te hebben en wat jij en je collega engineers leuk vinden. Je hebt ook al toestemming (en budget? Planning?) van je baas, maw je moet het nu potdomme ook nog gaan maken! En net zo goed (better even) als het pakket wat al 20 jaar tot volle tevredenheid gebruikt wordt. Da's niet makkelijk.

Herkenbare valkuilen waar je nu dus dreigt in te vallen : analysis paralysis en (god forbid) overengineering van de oplossing (jullie zijn geen Fortune 500 bedrijf volgens mij, dus probeer de problemen die daar bij horen niet op te lossen).

Mijn advies: Blijft zo dicht mogelijk bij de spirit van de huidige applicatie (shortcut keys much?) en maak het development proces incrementeel zodat je regelmatig (en vroeg in het proces) feedback krijgt van je gebruikers. Maak niet meer dan je (nu) nodig hebt.

Oh ja, en probeer geen goedkeuring te krijgen voor een WPF/.NET applicatie op een forum met voornamelijk web developers. Zonde van de energie.

Succes!

[sig69]

Ik zou persoonlijk toch voor winforms gaan. Alles wat je daarin maakt is voor gebruikers bekend want heel veel applicaties zien er zo uit. Met wpf zul je dus zelf heel veel styling moeten doen want out of the box is het niks (let wel: gebaseerd op mijn ervaringen van jaren geleden). Dus dan moet er eigenlijk ook al weer een designer op (dat was volgens mij ook een van de ideeën achter Silverlight en later wpf, dat designers en developers samen aan een project konden werken. Oh ja, Blend, weet u nog?). Nee, dat is 'm nooit geworden.
Ik zou dan wel je applicatie netjes opbouwen, separation of concerns etc. Voorbeeld uit de praktijk: ik heb ooit aan een applicatie gewerkt waarin alles een "service" was. Het enige wat de user interface deed was de services aansturen en data presenteren. Je moet dan denken aan een productservice, een orderservice, een analyseservice. Het mooie was dat al deze services lokaal of remote konden draaien. Voor klanten verkochten we dit dus als "fat client" (alles draaide lokaal), maar wij draaiden zelf 100% remote. Waarbij de analyservice uiteindelijk een cluster van calculationservices aanriep in plaats van 1. Later hebben we de orderservice bijvoorbeeld vervangen door een cachingorderservice, omdat directe crud op de database niet genoeg was.
Anyway, lang verhaal: bezint eer ge begint en maak er wat moois van

[Alex)]

Ik zou je toch willen adviseren om serieus te kijken naar het bouwen van een webapplicatie. Steeds meer mensen gebruiken mobiele apparaten (of niet-Windows apparaten, zoals Chromebooks) en in de komende jaren zullen deze mensen ook steeds meer in jullie bedrijf komen te werken. Die maak je niet blij met een WinForms-applicatie die alleen maar draait op een bedrijfslaptop.

Je hebt zo te horen een kans om het 'helemaal opnieuw te doen': grijp die kans dan ook en blijf niet vasthangen in ouderwetse technologieën en manieren van werken. Salesforce zou nooit zo groot zijn geworden als ze een Win32-applicatie hadden gebouwd.

En web applicatie is niet wenselijk, omdat er schermen zijn die met elkaar communiceren.

Als in: master/detail? Ook dat kun je in een webapplicatie prima bereiken. Kijk maar hoe Salesforce zoiets bijvoorbeeld doet.

En heel veel andere dingen waarvoor je vroeger een Win32-applicatie nodig had, kun je tegenwoordig net zo goed in een browser doen.

Bovendien kun je in een browser minder makkelijker zoveel informatie kwijt als in een desktop applicatie.

Usability is een vak apart! Een desktopapplicatie die 'heel veel informatie tegelijk toont' is zelden bruikbaar voor de eindgebruiker, omdat die overladen wordt door informatie en daardoor flink wat tijd kwijt is aan het destilleren van wat hij/zij nodig heeft.

[Rolandow]

Wauw, wat een reactie's. Ik ben (nog) geen heavy forum gebruiker, dus ik moet mezelf aanwennen om wel elke dag even te kijken.

Afvalzak schreef op dinsdag 5 februari 2019 @ 20:08:
Is het een idee om een groot software bedrijf met veel ervaring de basis op te laten zetten waarop jullie kunnen voortzetten, daar kunnen jullie verschrikkelijk veel van leren en je loopt niet tegen de, voor ervaren partijen bekende, valkuilen aan?

Het is zeker een optie om een groot bedrijf de basis op te laten zetten. Alleen ben ik door schade en schande wijs geworden; de meeste bedrijven zijn er niet gebaat bij om jou op die manier te helpen. Dus ze nemen de opdracht aan voor een bepaald bedrag, en als het budget op is, blijkt het project pas op 20% te zitten. Als er een bedrijf zou zijn waarvan ik zeker weet ik we ze kunnen vetrouwen, en dat ze niet proberen zoveel mogelijk uren bij ons weg te zetten, zou dit zeker een optie zijn. In feite is dat ook een beetje wat we momenteel proberen te vinden.

BugBoy schreef op dinsdag 5 februari 2019 @ 20:27:
Zelf een ERP pakket schrijven is bijna altijd een slecht idee.

Ik snap je zorgen, heus, echt waar. Normaal gesproken zou ik ook een slecht idee vinden. Gebruik zoveel mogelijk wat er op de markt is, en conformeer je naar die standaarden. We hebben daar dus ook naar gekeken, maar zijn tot de conclusie gekomen dat ons bedrijf juist goed functioneert omdat we in alles onze eigen weg hebben gekozen, en kunnen kiezen.

BugBoy schreef op dinsdag 5 februari 2019 @ 20:27: Het is Windows only en dus niet te gebruiken vanaf een mobiel apparaat. Dat wordt een steeds groter nadeel.

Windows only is voor ons geen enkel probleem, we zullen hier echt overstappen op mac's of linux. Daarnaast heb ik de afgelopen tijd ook een Angular applicatie gemaakt, maar met een pakket van deze omvang zie ik dat niet echt zitten. Niet alleen qua code base, maar ook zoals ik al eerder zei de mogelijkheid om deze hoeveelheden informatie te tonen. Bij een web applicatie wil je het toch responsive maken, geschikt voor touch screens. Als ik dan bijv. naar bootstrap kijk, dan is het allemaal veel lomper dan wat we nu op het scherm presenteren.

BugBoy schreef op dinsdag 5 februari 2019 @ 20:27: Als ik jouw posts bekijk dan wil je in eerste instantie geen gebruik maken van client/server, maar een enkele applicatie die de database aanspreekt. Met meerdere instanties ga je geheid tegen locking issues aanlopen.

Locking issues hebben we besproken. Het werkt nu zo dat een record gelocked wordt zodra het scherm open staat. Dan kun je wel nagaan hoe 'concurrent' de applicatie hoeft te zijn. Met dat in het achterhoofd denk ik dat we locking wel kunnen regelen. We kunnen het record op een onChange event locken, of we kunnen optimistic locking gebruiken. De kans dat er mensen echt in exact hetzelfde record zitten te bewerken (dus niet lezen) is niet zo groot, en dan zou een foutmelding best kunnen volstaan. Bij een web applicatie krijg je locking er trouwens ook niet gratis bij dus daar heb je dat probleem ook.

BugBoy schreef op dinsdag 5 februari 2019 @ 20:27: Om eerlijk te zijn denk ik dat jullie er echt te makkelijk over denken. De kans dat het management te hoge verwachtingen heeft die jullie niet waar gaan maken is levensgroot.

Dat is niet zo. We hebben maanden onderzoek gedaan, ook naar bestaande platformen, en uiteindelijk is deze keuze samen met management gemaakt.

DJMaze schreef op dinsdag 5 februari 2019 @ 22:02:
Ook al ben ik het eens met BugBoy.
Ik denk dat we waarschijnlijk te groot denken.

Dat denk ik ook, eerlijk gezegd, al waardeer ik alle reactie's evenveel. Het is in elk geval geen UWV, belastingdienst, NS, of bedrijf van die grootte. Als er een dag geen IT zou zijn, draait het bedrijf gewoon vrolijk verder, en grijpen we terug op het bonnetjes systeem (pen en papier). Uiteraard is onze keuze daar ook op gebaseerd.

farlane schreef op woensdag 6 februari 2019 @ 21:29:
In feite heb je je keuzes al gemaakt volgens mij (en volgens mij geen slechte) op basis van het type bedrijf waar je werkt, wat je denkt nodig te hebben en wat jij en je collega engineers leuk vinden. Je hebt ook al toestemming (en budget? Planning?) van je baas, maw je moet het nu potdomme ook nog gaan maken! En net zo goed (better even) als het pakket wat al 20 jaar tot volle tevredenheid gebruikt wordt. Da's niet makkelijk.

Dit is het precies, spijker op zijn kop! En vergeet niet: het IS al een keer gemaakt door onszelf. Zoals bij alle klussen gaat het de tweede keer altijd sneller en beter dan de eerste keer. Dat is een belangrijk voordeel. Misschien komt het bericht ook over alsof we allemaal complete newbies zijn, maar dat is ook niet zo. Alle programmeurs hebben 15 jaar of meer ervaring, alleen niet zoveel jaar met C#. Waarom we dan voor C# kiezen? Omdat we denken dat het toekomst bestendig is. Ik vind het een erg intuitive taal, op zich kom je er zo mee weg. Het gaat alleen even om de tools. Ik hoor liever nu dat we better Dabber kunnen gebruiken dan Entity Framework, dan dat ik er na een half jaar puzzelen zelf achter kom, en dat half jaar dus verspilt heb. De mensen die dat echt kunnen weten naar mijn mening, zijn de mensen die er dagelijk mee werken.

farlane schreef op woensdag 6 februari 2019 @ 21:29: Herkenbare valkuilen waar je nu dus dreigt in te vallen : analysis paralysis en (god forbid) overengineering van de oplossing (jullie zijn geen Fortune 500 bedrijf volgens mij, dus probeer de problemen die daar bij horen niet op te lossen).

Analysis paralysis, leuke uitdrukking. Zo voel ik mezelf af en toe ja, als ik bezig ben me te verdiepen in het ene onderwerp, en daardoor verzand in allerlei andere onderwerpen. Voor mij heeft dat dus vooral te maken met het structureren van de code, en dit maintainable houden. Problemen van een Fortune 500 bedrijf proberen we gelukkig niet op te lossen. We zijn een vrij nuchter bedrijf en doen ons niet groter voor dan we zijn. Dat is heel erg fijn.

farlane schreef op woensdag 6 februari 2019 @ 21:29: Mijn advies: Blijft zo dicht mogelijk bij de spirit van de huidige applicatie (shortcut keys much?) en maak het development proces incrementeel zodat je regelmatig (en vroeg in het proces) feedback krijgt van je gebruikers. Maak niet meer dan je (nu) nodig hebt.

Dit is inderdaad exact de planning. De eerste stap is zoveel mogelijk de oude applicatie overnemen. Natuurlijk pakken we per onderdeel gelijk dingen mee van de wensenlijst indien mogelijk. En natuurlijk verbeteren we gelijk routines die nu slecht zijn, of meerdere keren zijn geimplementeerd. Maar de eerste fase is vooral bedoeld om de huidige applicatie over te nemen. En dan inderdaad proef draaien, terwijl het oude systeem nog in de lucht is, met de onderdelen die af zijn.

Echter realiseer je je nu pas wat er standaard al allemaal in de applicatie zit. Save warnings als het scherm gesloten wordt. Authorisatie, waardoor menu's verschillend zijn, maar ook functies binnen een window. Validatie van invoervelden. Shortcuts inderdaad, als je bij ons +6 in een datumveld zet, telt hij 6 dagen bij vandaag op. Dus dan wil ik natuurlijk een eigen user control maken waar dit allemaal in zit, maar oja, ik was eigenlijk bezig met de validatie. And so on, and so on.

farlane schreef op woensdag 6 februari 2019 @ 21:29: Oh ja, en probeer geen goedkeuring te krijgen voor een WPF/.NET applicatie op een forum met voornamelijk web developers. Zonde van de energie.

Misschien ook wel een goede. Ik had me niet gerealiseerd dat het vooral web development is. Ik dacht dat dit C# hoekje was :-)

Alex) schreef op donderdag 7 februari 2019 @ 01:20: Je hebt zo te horen een kans om het 'helemaal opnieuw te doen'

Nee, niet echt. We hebben juist gekozen om de applicatie zoveel mogelijk hetzelfde te houden. Onder de motorkap verandert alles, maar naar de gebruiker toe niet. Leuk voor Salesforce dat ze zo groot zijn geworden, maar dat is ons doel helemaal niet. Het is een applicatie die onze interne processen ondersteunt. Niet een applicatie die we proberen te verkopen aan derden.

Alex) schreef op donderdag 7 februari 2019 @ 01:20:
Usability is een vak apart! Een desktopapplicatie die 'heel veel informatie tegelijk toont' is zelden bruikbaar voor de eindgebruiker, omdat die overladen wordt door informatie en daardoor flink wat tijd kwijt is aan het destilleren van wat hij/zij nodig heeft.

Usability is inderdaad een vak apart. Maar de schermen zijn nu juist precies afgestemd voor onze gebruikers, omdat we onze gebruikers direct verdienen. Vaak komt er alleen maar meer informatie bij in een scherm. En dat is de kracht ook juist; men kan in 1 oog opslag zien hoe een project ervoor staat.

Als je denkt dat we een applicatie schrijven om te verkopen, is je standpunt nog veel begrijpelijker, maar dat is dus niet zo. Het is alleen voor onszelf.

[Rolandow]

sig69 schreef op donderdag 7 februari 2019 @ 00:36:
Ik zou persoonlijk toch voor winforms gaan. Alles wat je daarin maakt is voor gebruikers bekend want heel veel applicaties zien er zo uit. Met wpf zul je dus zelf heel veel styling moeten doen want out of the box is het niks (let wel: gebaseerd op mijn ervaringen van jaren geleden).

Volgens dit document van microsoft is WinForms op zich inderdaad sneller en makkelijker om mee te ontwikkelen. Maar er staat ook dat als je over wilt stappen naar UWP, je dan alles volledig opnieuw moet doen. Daarnaast had ik verwacht dat je een soort stylesheet sausje over je hele project kunt gooien, dus vandaar de keuze voor WPF.

Ook dit is in elk geval onderzocht, voordat we de keuze maakten.

En ik moet zeggen, ik vind dat xaml helemaal zo gek nog niet. Het geeft een goed overzicht over de structuur van je layout.

[scosec]

Vergeet niet dat naast het eenmalig neerzetten van een project ook erg veel onderhoud met zich meebrengt.

Ik weet niet wat voor omvang jullie tech afdeling heeft (of je moet zelf in een ontwikkelhuis werken) maar wij kiezen er in ons bedrijf voor om dit soort projecten te beleggen bij tech partners. Je moet rekening houden met verloop van medewerkers en daarmee kennis. Tevens houd het velen van jullie fte bezet welke zich beter ergens anders op kunnen richten. Uiteindelijk zit jullie bedrijf met de gebakken peren.

Wij kiezen er dus voor om projecten te beleggen bij een ontwikkelhuis. Zij zijn dan verantwoordelijk voor het op pijl houden van kennis en ontwikkeling van de software.

Het feit dat je hier vraagt om advies over technieken die je moet in zetten geeft voor mij voldoende signaal af dat je hier niet zelf aan moet beginnen.

[Rolandow]

scosec schreef op donderdag 7 februari 2019 @ 09:04:
Vergeet niet dat naast het eenmalig neerzetten van een project ook erg veel onderhoud met zich meebrengt.

Ik weet niet wat voor omvang jullie tech afdeling heeft (of je moet zelf in een ontwikkelhuis werken) maar wij kiezen er in ons bedrijf voor om dit soort projecten te beleggen bij tech partners. Je moet rekening houden met verloop van medewerkers en daarmee kennis. Tevens houd het velen van jullie fte bezet welke zich beter ergens anders op kunnen richten. Uiteindelijk zit jullie bedrijf met de gebakken peren.

Wij kiezen er dus voor om projecten te beleggen bij een ontwikkelhuis. Zij zijn dan verantwoordelijk voor het op pijl houden van kennis en ontwikkeling van de software.

Het feit dat je hier vraagt om advies over technieken die je moet in zetten geeft voor mij voldoende signaal af dat je hier niet zelf aan moet beginnen.

Met alle respect, maar dan heb je het niet helemaal goed begrepen :-)

Ten eerste hebben we juist slechte ervaring met softwarehuizen, omdat je daar op een bepaald moment een nummertje wordt, en ze geen tijd meer voor je hebben. Of de prijzen voor dat werk worden opgeschroefd.

Ik vraag hier niet om me te leren programmeren, ik vraag om tips en/of ervaring wat de beste methodieken zijn, zodat we ons daar direct op kunnen richten in plaats van alle varianten te moeten uitzoeken.

Als we alles wat nieuw is moeten uitbesteden aan een ander bedrijf, dan kunnen we de deuren wel sluiten. Nieuwe technieken omarmen en eigen maken doen we liever, en daar lijkt me ook niks mis mee.

Je blijft toch ook niet eeuwig met Windows 98 werken, omdat je daar zo goed van weet hoe het werkt?

[CurlyMo]

@Rolandow wat eerder al is gezegd. Huur voor zeg 6 maanden een ZZP'er in die hier ervaring in heeft. Laat hem/haar een tijdje het voortouw nemen. Dat heeft meerdere voordelen. Je begint direct met productie draaien i.p.v. meerdere proof-of-concepts om de taal te leren kennen, je hebt iemand met ervaring die jullie van de grootste valkuilen kan behoeden, en je hebt iemand om vragen aan te stellen die direct betrekking hebben op jullie situatie i.p.v. anonieme forum leden met expertise in tig verschillende contexten. Zo iemand erbij is alleen wel duurder en gezien jullie kennis van C# is de vraag of je snel genoeg doorhebt of zo iemand er zelf geen potje van maakt.

[scosec]

Rolandow schreef op donderdag 7 februari 2019 @ 09:11:
[...]


Met alle respect, maar dan heb je het niet helemaal goed begrepen :-)

Ten eerste hebben we juist slechte ervaring met softwarehuizen, omdat je daar op een bepaald moment een nummertje wordt, en ze geen tijd meer voor je hebben. Of de prijzen voor dat werk worden opgeschroefd.

Ik vraag hier niet om me te leren programmeren, ik vraag om tips en/of ervaring wat de beste methodieken zijn, zodat we ons daar direct op kunnen richten in plaats van alle varianten te moeten uitzoeken.

Als we alles wat nieuw is moeten uitbesteden aan een ander bedrijf, dan kunnen we de deuren wel sluiten. Nieuwe technieken omarmen en eigen maken doen we liever, en daar lijkt me ook niks mis mee.

Je blijft toch ook niet eeuwig met Windows 98 werken, omdat je daar zo goed van weet hoe het werkt?

CurlyMo schreef op donderdag 7 februari 2019 @ 09:20:
@Rolandow wat eerder al is gezegd. Huur voor zeg 6 maanden een ZZP'er in die hier ervaring in heeft. Laat hem/haar een tijdje het voortouw nemen. Dat heeft meerdere voordelen. Je begint direct met productie draaien i.p.v. meerdere proof-of-concepts om de taal te leren kennen, je hebt iemand met ervaring die jullie van de grootste valkuilen kan behoeden, en je hebt iemand om vragen aan te stellen die direct betrekking hebben op jullie situatie i.p.v. anonieme forum leden met expertise in tig verschillende contexten. Zo iemand erbij is alleen wel duurder en gezien jullie kennis van C# is de vraag of je snel genoeg doorhebt of zo iemand er zelf geen potje van maakt.

Dat is ook een prima oplossing idd.

[Gomez12]

Rolandow schreef op donderdag 7 februari 2019 @ 09:11:
[...]
Je blijft toch ook niet eeuwig met Windows 98 werken, omdat je daar zo goed van weet hoe het werkt?

Met alle respect, maar dat is juist wel jullie wens.

Ipv een standaard ERP pakket te pakken wat een hedendaagse denkwijze achter zich heeft zitten willen jullie binnen je huidige werkwijze blijven en dat in principe gewoon namaken in een nieuw jasje.

Ik zou ook goed nagaan wat het management en de boekhouding wil, het is vrij simpel om een programma te maken voor ongeveer de rest van het personeel, maar boekhouding en management heeft in mijn ervaring simpelweg een rijtje vaste eisen die ook nog weleens vanuit wetgeving wijzigen.
En het is veelal toch wat belangrijker dat de boekhouder elke 1e van de maand een goed rapport naar management kan brengen dan dat een verkoper een goed rapport heeft.

Dat is ook exact wat ik in de reacties van @anboni proef, als het erp voor niemand werkt is het management gek als ze niet terug gaan naar het vorige. Maar als het beter werkt voor management en niet voor anboni, tja dan heeft anboni gewoon pech.

In mijn dagelijkse werk werk ik met allerlei koppelingen van erp-systemen naar ons toe en ik kan er feilloos uitpikken wat de zelfbouw-systemen zijn en wat niet. En dat is niet positief gesteld.

Laat ik eens een praktisch probleem van begin dit jaar pakken, weet jij hoe je moet omgaan met de btw-wijziging van 6 naar 9% procent als je goederen vooruitbetaald (oftewel je bestelt en betaald in december, het wordt pas in januari geleverd, hoe moet dat in je boekhouding staan)
Een standaard erp-pakket zoekt dat voor je uit en brengt een fix uit voor januari, maar kunnen jullie dit intern ook doen?

[servies]

Gomez12 schreef op donderdag 7 februari 2019 @ 09:38:
[...]

Met alle respect, maar dat is juist wel jullie wens.

Dat haal ik er niet uit, wat ik er wel uit haal is dat veranderen om het veranderen niet gewenst is, verandering om dingen te verbeteren daarentegen...

Ipv een standaard ERP pakket te pakken wat een hedendaagse denkwijze achter zich heeft zitten willen jullie binnen je huidige werkwijze blijven en dat in principe gewoon namaken in een nieuw jasje.

De meeste ERP pakketten gaan uit van een standaard aanpak van alles. Bij dienstverlenende bedrijven zal dat goed tot redelijk goed te mappen zijn, maar zodra je in de maak industrie komt gaat dat zeer vaak niet op omdat productieprocessen extreem specifiek/afwijkend kunnen zijn.
Ik heb van beide kanten ervaring. Ik heb jarenlang voor een ERP leverancier gewerkt die heel specifiek een pakket voor drukkerijen maakte. Van grote ERP leveranciers zoals SAP en vroeger Baan hebben ze toen nooit concurrentie gehad omdat die nooit het hele proces van een drukkerij goed onder de knie kregen...

Bij mijn huidige werkgever is zelf een ERP pakket ontwikkeld met behulp van een Software Factory en hier worden nog steeds door ons uitbreidingen en aanpassingen op gemaakt. We worden regelmatig door ERP leveranciers gebeld voor hun oplossing, maar ze kunnen nooit leveren wat wij nodig hebben (ook de technische kant van de productie/producten zit in het pakket).

Ik zou ook goed nagaan wat het management en de boekhouding wil, het is vrij simpel om een programma te maken voor ongeveer de rest van het personeel, maar boekhouding en management heeft in mijn ervaring simpelweg een rijtje vaste eisen die ook nog weleens vanuit wetgeving wijzigen.
En het is veelal toch wat belangrijker dat de boekhouder elke 1e van de maand een goed rapport naar management kan brengen dan dat een verkoper een goed rapport heeft.

Als het huidige pakket ook al intern gebouwd is, dan verwacht ik dat de kennis voor dat soort regeltjes en hoe die toegepast moeten worden wel intern aanwezig is

In mijn dagelijkse werk werk ik met allerlei koppelingen van erp-systemen naar ons toe en ik kan er feilloos uitpikken wat de zelfbouw-systemen zijn en wat niet. En dat is niet positief gesteld.

Mijn ervaring vanuit mijn vorige werk is dat de leveranciers van producten waar wij naar toe moesten koppelen (op vraag van klanten) een enorm hoge dunk van zichzelf hadden... Uiteindelijk kwam het er (veel te) vaak op neer dat wij hun gepruts moesten oplossen

Laat ik eens een praktisch probleem van begin dit jaar pakken, weet jij hoe je moet omgaan met de btw-wijziging van 6 naar 9% procent als je goederen vooruitbetaald (oftewel je bestelt en betaald in december, het wordt pas in januari geleverd, hoe moet dat in je boekhouding staan)
Een standaard erp-pakket zoekt dat voor je uit en brengt een fix uit voor januari, maar kunnen jullie dit intern ook doen?

Ik mag hopen dat die standaard ERP leverancier die fix al begin vorig jaar heeft uitgebracht of daar al een standaard voorziening voor had (dit is niet de eerste keer dat de btw is gewijzigd)... Contracten bij bedrijven lopen vaak iets langer dan een maandje...

[Mrlten]

Als het een Windows applicatie moet gaan worden, dan zou je ook naar DevExpress XAF kunnen kijken. Die genereerd aan de hand van het datamodel (Entity Framework / XPO) de UI. Alle schermen, CRUD acties en opzoeklijstjes zit er automagisch al in Als developer hoef je dan alleen nog de schermen wat netter in te richten en/of extra knoppen toe te voegen.

Een scherm wat een week bouwen zou zijn, is met XAF een klein uurtje werk. Ook kan de eindgebruiker nog de schermen/tabellen naar eigen smaak inrichten

[Willem_D]

Ik zou kiezen voor WinForms in jouw geval. WPF kan ook, maar dan moet je de UI in XAML maken, en dat is wat onhandiger.

UWP zou ik niet doen, dat heeft geen meerwaarde. Het bied geen extra voordelen (alleen maar extra restricties), en het is maar de vraag of (en hoe lang) Microsoft doorgaat met UWP.

Miscrosoft is een beetje wispelturig de laatste jaren. Silverlight was bijvoorbeeld de beloofde technologie van de toekomst, tot het moment dat ze ermee stopten. Van Winforms heb ik wel het idee dat het over 20 jaar nog bestaat.

[jip_86]

Kijk goed welke ontwerpkeuzes in je oude applicatie nu tegen je werken. Dus wat voor mogelijkheden zou je graag willen, maar kun je op dit moment niet gebruiken omdat je huidige framework dit nu niet toe laat. Dat is informatie die je nodig hebt om je nieuwe ontwerp op te gaan zetten.

Daarnaast zijn er heel veel goede WPF controls die je kan kiezen om je je werk een stuk gemakkelijker te maken. Ook hier is een goede inventarisatie weer van belang, neem aan dat je grids hebt, grafieken en een printcomponent zal je ook in WPF weer nodig hebben. Hier kan je vaak met trials al mee werken om te kijken welke het beste aansluit bij wat je nodig hebt.

Verder is het belangrijk goed je lagen te scheiden. Business van presentatie scheiden zodat je zo min mogelijk werk hebt mocht je toch een webpagina er voor willen bouwen.

[FeronIT]

Zelf ben op dit moment hetzelfde aan het doen. Een oude VB6 applicatie omschrijven naar Winforms. De keuze voor Winforms was vrij eenvoudig en moet hardware aangestuurd worden en dat is nagenoeg onmogelijk voor vanuit een webapp. WPF had ook gekund, maar Winforms is altijd sneller.
Wij hebben gekozen voor een oplossing waarbij modules van de oude applicatie IN de nieuw applicatie geladen worden. Als je bv in het menu op klanten --> beheer klikt wordt in de nieuwe applicatie het oude scherm geladen. Steeds als een module omgebouwd is naar de nieuwe opzet wijzigt het menu en start de het nieuwe scherm. Op deze manier kun je stapje voor stapje over. (zomaar een tip)
Qua techniek is de keuze gevallen op een WebAPI waarin welke JSON data heen en weer stuurt. De Winforms app haalt alle data op en slaat deze op via deze WebAPI. Dat heeft als groot voordeel, naast alles van separation of concerns, je ook makkelijk bepaalde delen via een Webapp/ mobile app beschikbaar kunt maken.
Wij maken verder geen gebruik van frameworks, een intern systeem moet jaren meegaan en de meeste frameworks sterven regelmatig of worden voorzien van breaking updates wat beide voor veel ellende zorgt.
Voor de UI hebben we eigen controles geschreven die voor ons voldoen. Een textbox met een label erboven, op die manier hebben alle textboxen dezelfde layout en afmeting waardoor het geheel consistent blijft.
DM me maar eens als je wat meer wilt sparren

[BertS]

Mrlten schreef op donderdag 7 februari 2019 @ 11:05:
Als het een Windows applicatie moet gaan worden, dan zou je ook naar DevExpress XAF kunnen kijken. Die genereerd aan de hand van het datamodel (Entity Framework / XPO) de UI. Alle schermen, CRUD acties en opzoeklijstjes zit er automagisch al in Als developer hoef je dan alleen nog de schermen wat netter in te richten en/of extra knoppen toe te voegen.

Een scherm wat een week bouwen zou zijn, is met XAF een klein uurtje werk. Ook kan de eindgebruiker nog de schermen/tabellen naar eigen smaak inrichten

Inderdaad. XAF is in mijn ervaring een uitblinker in de application-frameworks. Daar zijn er talloze van, maar bij de meeste loop je vast op uitbreidbaarheid/aanpasbaarheid.
Wat @Rolandow noemde:

Rolandow schreef op donderdag 7 februari 2019 @ 08:39:
Echter realiseer je je nu pas wat er standaard al allemaal in de applicatie zit. Save warnings als het scherm gesloten wordt. Authorisatie, waardoor menu's verschillend zijn, maar ook functies binnen een window. Validatie van invoervelden. Shortcuts inderdaad, als je bij ons +6 in een datumveld zet, telt hij 6 dagen bij vandaag op. Dus dan wil ik natuurlijk een eigen user control maken waar dit allemaal in zit, maar oja, ik was eigenlijk bezig met de validatie. And so on, and so on.

- save warnings: default gedrag
- authorisatie: configureren, verder allemaal voorzien. Niet alleen in GUI, maar ook in je businesslogica
- validatie: configureren/definiëren
- die +6 zit er dan niet in (voor zover ik weet), maar daarvoor maak je een eigen DatePropertyEditor en je kunt hem overal toepassen

GUI (navigatie, schermen) wordt gegenereerd obv (definieerbaar) model, maar als je echt custom-custom-custom wilt, kun je ook gewoon je eigen Winforms.Form bouwen en integreren in het geheel.

Qua stabiliteit: het bestaat inmiddels 10+ jaar (misschien al wel 15, ik meen me een start van 2004 te herinneren) en wordt actief doorontwikkeld.
En wil je later toch iets op andere platforms? Web en Mobile is ook beschikbaar.

Heeft het geen nadelen dan? Jawel, de leercurve. Doordat er zoveel plumbing voor je is weggehaald, moet je er echt wel even in komen. Dat heeft echter weer het voordeel dat je de tijd steekt in de niet-standaard dingen, en alle CRUD kost nauwelijks tijd.

Zelf werk ik momenteel als ZZP'er mee aan zo'n traject waar we dit met XAF invullen. Qua tijd ben ik nogal bezet momenteel, maar DM gerust voor meer info.

[Gertjuhjan]

Ik zou never en nooit een winforms applicatie maken. Als je dan persé een windows applicatie wilt, zou ik gaan voor WPF met MVVM pattern. Je kan dit clean doen of met behulp van een framework.

Het geeft een stuk betere onderhoudbaarheid van de code dan windows forms. Als je zoekt op WPF VS WIndows zijn er genoeg vergelijkingen te vinden, zodat je je eigen keuze kan maken hierin.

Wat betreft inhuur en jullie ervaring op C#/.NET platform, zou ik zeker een freelancer of detachering inhuren voor een paar maanden. Zo iemand kan met jullie mee het platform en de structuur neerzetten. Niet alleen op software gebied, maar wellicht ook op een agile werkwijze.

Ook kan hij/zij jullie wegwijs in best practices, clean code en designpatterns in C# leren.

[ Voor 49% gewijzigd door Gertjuhjan op 07-02-2019 16:32 ]

[ocf81]

Ik zou toch eens onderzoeken of je niet op de een of andere manier de presentatielaag en de verwerkingslaag van elkaar kan scheiden. Op die manier kan je makkelijker mee met de platformen van de toekomst zonder dat je hele applicatie herschreven hoeft te worden.

[jos707]

WPF is reeds meermaals afgeraden geweest in enkele posts hierboven. Deze wil ik volledig bijtreden, je gaat een applicatie bouwen met een technologie stack die reeds verouderd is. Moderne applicaties worden nog zelden als desktop-only gebouwd tenzij hiervoor heel goede redenen zijn.

Het gros van de huidige .NET applicaties zijn web-based en bestaan uit een front-end (vb AngularJS), een backend draaiend op een server (vb C# MVC met Entity framework) en een database component (vb SQL server).

[ocf81]

Je kan op zich wel een WPF front end maken en die later vervangen door iets anders. Als je daar nu rekening mee houdt, dan is de pijn een stuk minder groot wanneer je dat gaat doen.

[Rolandow]

Gomez12 schreef op donderdag 7 februari 2019 @ 09:38:
Ipv een standaard ERP pakket te pakken wat een hedendaagse denkwijze achter zich heeft zitten willen jullie binnen je huidige werkwijze blijven en dat in principe gewoon namaken in een nieuw jasje.

Het gaat helemaal niet om het jasje. Dat jasje ziet er misschien momenteel ouderwets uit, maar dat is het probleem helemaal niet. Het gaat juist om de onderliggende techniek die niet onderhoudbaar is. Voor een nieuwe programmeur is het huidige pakket qua techniek bijna niet te doorgronden. Dit komt deels door de manier van programmeren, maar voor een groot deel ook door de beperkingen van het pakket. Zowel qua code als database.

Gomez12 schreef op donderdag 7 februari 2019 @ 09:38:
Ik zou ook goed nagaan wat het management en de boekhouding wil, het is vrij simpel om een programma te maken voor ongeveer de rest van het personeel, maar boekhouding en management heeft in mijn ervaring simpelweg een rijtje vaste eisen die ook nog weleens vanuit wetgeving wijzigen.

Het is me niet helemaal duidelijk hoe je de indruk hebt gekregen dat we niet weten wat management en boekhouding wil. Management is actief betrokken geweest bij de ontwikkeling van het pakket zoals het nu is, en krijgt juist exact te zien wat ze willen. Het liefst zouden ze nog 20 jaar doordraaien met dit pakket.

Gomez12 schreef op donderdag 7 februari 2019 @ 09:38:
Laat ik eens een praktisch probleem van begin dit jaar pakken, weet jij hoe je moet omgaan met de btw-wijziging van 6 naar 9% procent als je goederen vooruitbetaald (oftewel je bestelt en betaald in december, het wordt pas in januari geleverd, hoe moet dat in je boekhouding staan)
Een standaard erp-pakket zoekt dat voor je uit en brengt een fix uit voor januari, maar kunnen jullie dit intern ook doen?

Ik ben geen boekhouder, dus ik weet niet exact de oplossing voor dit probleem. Ik weet wel dat als dit soort dingen langskomen, wij binnen een paar uur een fix hebben. We kunnen dan exact de oplossing implementeren die we zelf willen, en hebben dit snel voor elkaar. Bovendien valt dit te plannen. Bij een grote leverancier moet je maar weer afwachten wanneer ze tijd hebben om naar jouw probleem te kijken. Welke oplossing kiezen ze? Dit is juist precies de reden waarom we onze eigen software willen hebben; we zijn zelf in control en onafhankelijk van anderen.

servies schreef op donderdag 7 februari 2019 @ 10:51:
Dat haal ik er niet uit, wat ik er wel uit haal is dat veranderen om het veranderen niet gewenst is, verandering om dingen te verbeteren daarentegen...

Mijn Windows 98 opmerking ging over de opmerking van scosec dat mijn advies om de gevraagde technieken voldoende signaal af geeft om er niet aan te beginnen. Daarvan zeg ik; je moet niet bang zijn om nieuwe technieken te gebruiken, ook al zit hier een leercurve aan.

Het pakket an sich hoeft helemaal niet te veranderen, omdat het perfect is afgestemd op de bedrijfsprocessen. Maar het verandert juist iedere dag. Als iemand van het magazijn bij ons komt die zegt dat hij eerst het label wil scannen en dan de voorraad intoetsen, of juist andersom, dan kunnen we dat gewoon aanpasssen. Zo wordt het pakket continu verbeterd en slimmer gemaakt. Maar schermen (en dus processen) die af zijn en goed functioneren hoeven helemaal niet anders. Liever niet zelfs. Als we zouden overstappen naar een ander pakket, zou factureren ineens heel anders gaan. Ga al die collega's dat maar eens uitleggen.

Mijn ervaring is verder ook meer zoals @servies zegt. Zelf bouwers hebben soms misschien wat meer hulp nodig bij het integreren van een koppeling, maar dit komt misschien ook omdat die zelfbouwers 1 of 2 generaties ouder zijn. Dan is OAuth best een hele kluif om even te bevatten (als niet web developer). Maar als het eenmaal draait is het juist super flexibel. We kunnen in principe alles met een API koppelen aan ons pakket; en wij bepalen zelf of we dat doen, hoe snel we dat doen, en hoe we dat doen.

Mrlten schreef op donderdag 7 februari 2019 @ 11:05:
Als het een Windows applicatie moet gaan worden, dan zou je ook naar DevExpress XAF kunnen kijken.

Grappig, want deze tip heb ik nu meermaals voorbij zien komen. Ik kon het nog niet, maar naar aanleiding van deze discussie heb ik ook op YouTube wat video's bekeken. Het was werkelijk mind blowing. Het deed me erg denken aan het pakket van ThinkWise (low code platform). De video die ik keek was ook van een hele enthousiaste amerikaan die huppetee binnen een uur een kleine applicatie had draaien.

Tegelijkertijd vond ik het doodeng. Er gebeurt inderdaad zoveel op de achtergrond, dat ik bang ben dat we weer te afhankelijk worden van een te specifiek framework. Dat ze al zo lang bestaan is wel wat geruststellend, maar dat ik geen enkel idee heb wáárom dingen werken zoals ze werken vind ik dan weer eng. Maar ik denk dat ik het nog eens aan mijn collega ga voorleggen, zodat we dit toch nog eens beter kunnen evalueren. Lastige keuze; nu veel sneller ontwikkelen met veel afhankelijkheid... of zelf alles doen en exact weten hoe het in elkaar steeks. Ik realiseer me dat ik mezelf dan misschien een beetje tegen spreek als ik om veelgevraagde libraries vraag, maar een library vind ik toch wat anders dan een heel framework. We waren overigens wel al heel enthousiast over de controls van DevExpress, dus de leverancier was me al bekend :-).

Willem_D schreef op donderdag 7 februari 2019 @ 11:11:
Ik zou kiezen voor WinForms in jouw geval. WPF kan ook, maar dan moet je de UI in XAML maken, en dat is wat onhandiger.

UWP zou ik niet doen, dat heeft geen meerwaarde. Het bied geen extra voordelen (alleen maar extra restricties), en het is maar de vraag of (en hoe lang) Microsoft doorgaat met UWP.

Ik las dat UWP apps alleen via de store kunnen worden uitgerold inderdaad. Dat zal het voorlopig niet worden. Maar de extra leercurve van WPF vind ik op zich niet zo heel erg. Maar het scheiden van code met het MVVM pattern vind ik wel een mooie oplossing. Op de 1 of andere manier voelt WPF ook wel een beetje vertrouwt. Een website heb ik nooit nooit gemaakt met Dreamweaver, maar gewoon code kloppen met Homesite ofzo.

jip_86 schreef op donderdag 7 februari 2019 @ 11:29:
Kijk goed welke ontwerpkeuzes in je oude applicatie nu tegen je werken. Dus wat voor mogelijkheden zou je graag willen, maar kun je op dit moment niet gebruiken omdat je huidige framework dit nu niet toe laat. Dat is informatie die je nodig hebt om je nieuwe ontwerp op te gaan zetten.

Goede tip, maar dat is eigenlijk het probleem niet. Alles wat we willen doet het pakket wel. Het is alleen niet onderhoudbaar. Denk spaghetti code, geen versie beheer, geen relationele database, geen OO code (maar basic). De applicatie is nu zo groot, dat dit platform niet meer the right tool is, in elk geval niet zoals het nu is opgezet. De artikelen database is, voor dit pakket, bijna onwerkbaar geworden. Je kunt hier niet makkelijk een bulk actie op doen. Terwijl het aantal artikelen (nog geen 2mln) geen enkel probleem hoort te zijn voor een database. Met dat soort problemen gaan er bij mij lampjes branden dat dit vroeg of laat uit zijn voegen barst.

Maar wat ermee gemaakt is, qua werking, zit zo'n beetje alles erin wat ons hartje begeert. Natuurlijk zijn er altijd wensen om dingen nog beter en makkelijker te maken, maar we kunnen hier gewoon prima mee draaien.

jip_86 schreef op donderdag 7 februari 2019 @ 11:29:
Verder is het belangrijk goed je lagen te scheiden. Business van presentatie scheiden zodat je zo min mogelijk werk hebt mocht je toch een webpagina er voor willen bouwen.

Dit wil ik ook heel graag, maar we stoeien dus erg met de vraag; hoe dan. Een WebAPI is leuk, maar dat kan ook op een later moment. We hoeven maar een heel klein deel beschikbaar te hebben via mobile devices. Dus als we de business logic in services of iets hebben, dan is die API vervolgens snel ontwikkeld. Je hoeft alleen maar wat endpoints te maken en wat conversie te doen. Maar om nu al te beginnen om alles via een WebAPI te doen, terwijl dit voor het overgrote deel niet nodig is (en nu zeker geen prio heeft), vind ik eigenlijk zonde. Ook van de performance. Het lijkt me dat een rechtstreekse verbinding met de sql server veel sneller is dan het converteren van alle data naar JSON en weer terug. Beetje onzinnig. Voor nu.

Maar hoe je het dan wel goed scheid, dat is precies de expertise die we zoeken. Want hoe gaat dit samen met MVVM en Entity Framework. En is EF dan uberhaupt wel de juiste tool voor deze job. Dat zijn in hoofdlijnen vragen, maar als je gaat coderen kom je nog op veel specifiekere vragen uit. En daar zoeken we dus een sparrings partner voor :-). Om het topic maar weer even aan te halen ;-).

FeronIT schreef op donderdag 7 februari 2019 @ 11:35:
Zelf ben op dit moment hetzelfde aan het doen. Een oude VB6 applicatie omschrijven naar Winforms. De keuze voor Winforms was vrij eenvoudig en moet hardware aangestuurd worden en dat is nagenoeg onmogelijk voor vanuit een webapp. WPF had ook gekund, maar Winforms is altijd sneller.
[...]
DM me maar eens als je wat meer wilt sparren

Klinkt goed! Ik vrees dat wij de oude schermen niet kunnen embedden, maar zoals jij het doet lijkt me een mooie methode inderdaad. Daarnaast zullen we ook de database moeten aanpassen. Die database is niet benaderbaar vanuit C#, dus we kunnen helaas niet in dezelfde database werken als het oude pakket. Dat maakt faseren zoals jij hier noemt ook lastig. Dan zouden we een api moeten maken voor de oude database, en dat zou maanden extra werk kosten.

Ik ga WinForms nog eens voorleggen, maar dat voelt toch wel als een stapje 'terug', ouder. Misschien ook omdat Microsoft dat zelf zo aangeeft, las ik ergens. Wat ik ook mooi vind aan WPF is dat het al zoveel mogelijk responsive is. Ik weet niet hoe dat bij Winforms werkt? Buiten de extra leercurve zie ik op zich niet zoveel nadelen van WPF ten opzichte van Winforms.

Gertjuhjan schreef op donderdag 7 februari 2019 @ 12:32:
Wat betreft inhuur en jullie ervaring op C#/.NET platform, zou ik zeker een freelancer of detachering inhuren voor een paar maanden. Zo iemand kan met jullie mee het platform en de structuur neerzetten. Niet alleen op software gebied, maar wellicht ook op een agile werkwijze.

Dit is ook wel een optie, maar waar vind je zo iemand? Wat dat betreft heb ik weinig vertrouwen in detacheringsbureau's. Ik heb per ongelijk een bureau gebeld die "detachering & trainingen" adverteerde, om te kijken of we daar training konden krijgen. Het resultaat was een offerte die totaal niet aansloot op onze wensen, en daarna elke week telefoon van die partij of ze al iets voor ons konden betekenen. Dan weet ik wel genoeg zeg maar.

Detacheren is dus wel een optie, maar dan wil ik graag via de techneut zelf detacheren, en niet via account managers. Overigens krijgen we a.s. maandag evengoed zo'n account manager over de vloer, dus ook die mogelijkheden zijn we aan het bekijken.

ocf81 schreef op donderdag 7 februari 2019 @ 17:19:
Ik zou toch eens onderzoeken of je niet op de een of andere manier de presentatielaag en de verwerkingslaag van elkaar kan scheiden. Op die manier kan je makkelijker mee met de platformen van de toekomst zonder dat je hele applicatie herschreven hoeft te worden.

No offense, maar ik doe niet anders ;-). Onderzoeken, onderzoeken, onderzoeken, onderzoeken. Het ene onderzoek leidt weer het volgende onderzoek in.

Vermakelijk praktijk voorbeeld... ik twijfel of ik een Repository achtig pattern moet gaan gebruiken, om beter scheiding aan te kunnen brengen, en de code makkelijker testbaar te kunnen maken. Kom ik op deze schitterende blog uit, van iemand die me behoorlijk kundig lijkt, maak ik zo op uit zijn schrijfstijl. Ik worstel me door deel 1 en 2 van het artikel heen, probeer de generic en delegates te begrijpen die erin voorkomen, om vervolgens uit te komen bij deze post. En daarin zegt hij eigenlijk, vergeet die truly generic repositories... werkt niet. Hoppa, weer een paar uur van mijn leven kwijt.

Dat probeer ik dus te voorkomen. Studeren is niet erg, maar hoe weet ik dat ik het juiste studeer?

[Gertjuhjan]

Hoe vind je een software ontwikkelaar. Je zou hier op V&A een advertentie kunnen zetten voor het zoeken van een freelancer. Er is ook een freelance topic hier op tweakers en die hebben een Slack kanaal waar je opdrachten kan plaatsen.

Maar een detacheringsbedrijf (met accountmanager) heeft ook zo zijn voordelen. Want zij weten precies wat ze in huis hebben en wat het beste past bij jouw wensen.

[ocf81]

@Rolandow Ter verduidelijking waarom ik die suggestie doe heb ik die 2^e post net voordat je jouw reply postte neergezet. Misschien had ik die toevoeging gisteren al moeten doen.
Ik snap wel dat je minder tijd aan onderzoek wil spenderen, maar daar valt niet altijd even veel aan te doen. Jij bent/jullie zijn degene(n) die verantwoordelijk is voor de ontwikkeling. Wij kunnen alleen maar advies geven om ergens eens naar te kijken. Voor de onderbouwing van je keuzes zal je uiteindelijk je eigen overwegingen moeten maken, en daar is ook onderzoek voor nodig. Dit is nu eenmaal een onderdeel van greenfield ontwikkeling.

[Rolandow]

ocf81 schreef op vrijdag 8 februari 2019 @ 09:46:
@Rolandow Ter verduidelijking waarom ik die suggestie doe heb ik die 2^e post net voordat je jouw reply postte neergezet. Misschien had ik die toevoeging gisteren al moeten doen.
Ik snap wel dat je minder tijd aan onderzoek wil spenderen, maar daar valt niet altijd even veel aan te doen. Jij bent/jullie zijn degene(n) die verantwoordelijk is voor de ontwikkeling. Wij kunnen alleen maar advies geven om ergens eens naar te kijken. Voor de onderbouwing van je keuzes zal je uiteindelijk je eigen overwegingen moeten maken, en daar is ook onderzoek voor nodig. Dit is nu eenmaal een onderdeel van greenfield ontwikkeling.

Dat snap ik, en daar zijn we ook heus toe bereid. Naar dat advies zijn we feitelijk ook op zoek, maar dan ook een niveau dieper. Ik bedoel, iemand kan zeggen dat we Caliburn Micro, Entity Framework en Autofac het beste kunnen gebruiken, maar dan zou ik vervolgens ook graag met diegene willen sparren hoe ze dat in elkaar hebben gevlochten. Of misschien zijn er juist pakketten waar je beter verre vandaan kunt blijven.

Ik denk dat er libraries zijn die elkaar goed aanvullen, maar ook libraries kunnen zijn die elkaar afstoten of niet lekker samen werken.

Deze shoutout naar communities was in elk geval een poging om het proces eens van de andere kant te benaderen. In plaats van dat ik nog uren, dagen, weken op zoek ben naar alle verschillende libraries en hoe ze in elkaar te passen, is er misschien ook iemand die op basis van onze behoeften hier ervaring mee heeft. Dus ik dacht laat ik eens vragen, in plaats van zoeken. Wie weet wat het oplevert. Toen google ook met Tweakers kwam, waar ik toch al een account heb en regelmatig gebruik van heb gemaakt dacht ik kom, laat ik daar eens wat vragen :-)

[CodeIT]

Ik werk nu al een tijdje met de stack die je aanhaalt in je TS.
Wij gebruiken hier WPF + Caliburn Micro + AutoFac + Mahapps Metro. De laatste is voor de looks en integreert goed met Caliburn en Autofac. Er was een aardige leercurve, maar nu ik ermee bekend ben, wil ik niet snel meer iets anders. We maken nu een mooie schaalbare (hardware accelerated) UI, met een mooie scheiding door het gebruik van MVVM.
Dat er mensen nu nog Windows Forms preferen begrijp ik niet zo goed. Met WPF kun je visueel veel mooiere dingen bouwen die zeer goed performen. Met voordelen als UI virtualization, superieure databinding, resolutie onafhankelijkheid. Je kunt ook werkelijk alles aanpassen, mocht je dat willen.

Een praktisch voorbeeld waar ik nu mee zit is (heel simpel); hoe open ik een nieuw scherm vanuit mijn ShellViewModel waarbij ik de mogelijkheden van Autofac dus kan benutten?

Wij programmeren vooral in VB.NET:

code:

   Dim aboutVm = IoC.Get(Of AboutViewModel)
   _WindowManager.ShowDialog(aboutVm, Nothing, Nothing)

Ik ben begonnen met een klein projectje om alles onder de knie te krijgen. Daar wat dingen geleerd die beter konden en vervolgens toegepast op grotere projecten.

[Rolandow]

@CodeIT die weg volg ik nu ook; eerst klein beginnen zodat je kunt klooien wat je wilt, en dan verder. Alleen hebben wij dus C# gekozen ipv VB. Mahapps.Metro had ik ook al gezien, maar heb het nog niet toegevoegd om te proberen.

Voor wat betreft het praktisch voorbeeld: zoals jij het doet haal je nu zelf het object uit de container. Dat raadt Autofac eigenlijk af, maar misschien is er in dit geval geen betere manier.

Wat gebruiken jullie om de database te benaderen? We hadden eigenlijk voor Entity Framework gekozen, maar Dapper vind ik ook nog steeds wel mooi, omdat je dan meer in control bent.

[CodeIT]

Rolandow schreef op vrijdag 8 februari 2019 @ 10:26:
@CodeIT die weg volg ik nu ook; eerst klein beginnen zodat je kunt klooien wat je wilt, en dan verder. Alleen hebben wij dus C# gekozen ipv VB. Mahapps.Metro had ik ook al gezien, maar heb het nog niet toegevoegd om te proberen.

Voor wat betreft het praktisch voorbeeld: zoals jij het doet haal je nu zelf het object uit de container. Dat raadt Autofac eigenlijk af, maar misschien is er in dit geval geen betere manier.

Wat gebruiken jullie om de database te benaderen? We hadden eigenlijk voor Entity Framework gekozen, maar Dapper vind ik ook nog steeds wel mooi, omdat je dan meer in control bent.

Voor een simpel about window doen we het op deze manier. Voor complexere schermen gaat alles via de constructor. Autofac vult dan automatisch alle parameters in.
De reden dat we het voor een about window zo doen is dat we geen hele lange constructors krijgen. Ook spreken we Autofac niet direct aan, maar gaat IoC.Get<T> via Caliburn zodat we nog steeds makkelijk kunnen wisselen van DI.

De meeste van onze projecten gebruiken geen DB, het zijn vooral programma's op het gebied van video weergave/processing. Een project waarbij we wel een DB gebruiken, gebruiken we Entity Framework. We maken dan services die een deel van de data afhandeling doen. Bijvoorbeeld een CustomerService die (via EF) de klanten ophaalt, wijzigt etc. Het gebruik van een service ipv direct EF aanspreken vanuit een VM is zodat het beter te testen is en zodat we EF makkelijk kunnen inruilen voor iets anders, mochten we dat willen.

Enkele handige NuGet pakketten icm Caliburn zijn PropertyChanged.Fody (automatiche INotifyPropertyChanged) en Nlog voor logging

[oZy]

@Rolandow vanuit mijn 20 jaar ervaring met dit soort trajecten kan ik je het volgende advies meegeven:

• .NET is een prima platform waarin je alle aangedragen architectuuropties kwijt kunt
• De echte winst in dit project ligt in het database ontwerp + kans om modellen opnieuw te definiëren
• Nadrukkelijk advies om data/ui te scheiden dmv een api.
• Gebruik een centraal Identity platform voor het regelen van de authenticatie / autorisatie
• Als het echt in een desktop applicatie moet is WPF + MVVM een prima systeem

Ik heb in het verleden dezelfde onderzoekstrajecten als wat jij nu doet doorlopen bij de migratie van winforms applicatie naar een modern toekomstproof systeem. Daarbij hebben we deze aspecten naar alle tevredenheid geïmplementeerd. Ik zou een hoop tijd hebben gewonnen als ik dit soort lijstjes van te voren zou hebben gehad

De tooling die ik gebruik:
WebAPI met aspnetcore + entityframeworkcore
IdentityServer4 met Office365 (AzureAD) integratie voor SSO / Auth
VueJS + Vuex + VuetifyJS + Vuex-oidc voor web applicaties
MaterialDesignInXaml + Dragablz + CaliburnMicro voor WPF app


PS. generiek ERP systeem kan goed werken voor een generiek bedrijf, maar in feite is het, zeker met de tooling van nu en een goede programmeur, tegen vergelijkbare kosten als maatwerk op te zetten.

Doe het gestructureerd, en pas de scheiding in data/auth/ui in vredesnaam toe zodat het ook in de toekomst onderhoudbaar en uitbreidbaar blijft.

[whoami]

Ik blijf het maar vreemd vinden dat er opeens allerhande technologiën worden voorgesteld zonder dat de scope en requirements gekend zijn. Iedereen spuit hier natuurlijk zijn eigen favoriete / gekende tools / technieken.

Ik zie hier bv CQRS voorbijkomen; allemaal mooi en leuk, maar is dat wel nodig ? Je weet het momenteel niet of het nuttig is of enkel extra complexiteit zal toevoegen.

Dit is natuurlijk ook een brede vraag van de TS, en ik denk dat die eerst de scope & requirements moet vastleggen. Een aantal zaken die ik hier zie voorbijkomen zijn dan wel weer goede guidelines:
- UI & backend opsplitsen zodanig dat je later een extra UI interface kunt toevoegen
- van in het begin gebruik maken van CI / CD

Zowiezo moet je ook eerst eens gaan nadenken over hoe je wil overstappen. Wil je een 'big bang' doen, waarbij er op een dag gezegd wordt. Kijk, vanaf dag x gaan we met het nieuwe systeem werken, waarbij je over het weekend bv alle bestaande data converteert naar het nieuwe systeem, of wil je gefaseerd gaan werken (zoek eens op strangler pattern).

Rolandow schreef op donderdag 7 februari 2019 @ 08:39:

Het gaat alleen even om de tools. Ik hoor liever nu dat we better Dabber kunnen gebruiken dan Entity Framework, dan dat ik er na een half jaar puzzelen zelf achter kom, en dat half jaar dus verspilt heb. De mensen die dat echt kunnen weten naar mijn mening, zijn de mensen die er dagelijk mee werken.

Wie zegt dat ?
Dat hangt allemaal af van je wensen en je scope. EF is een full blown ORM die heel wat uit handen neemt, en dan natuurlijk een steile leercurve heeft en waarmee je jezelf in de voet kunt schieten als je het niet goed gebruikt.
Dapper is lightweight en neemt dus minder uit handen, wat dan wil zeggen dat je zelf meer controle hebt, maar ook meer zelf moet doen (zelf de queries schrijven bv).
Het hangt er allemaal vanaf wat je precies wil, en het ene sluit het andere daarom niet uit. IMO kan je voor module X perfect bv EF gebruiken en voor module Y Dapper (als je een goede basis architectuur hebt uitgewerkt).

[ Voor 31% gewijzigd door whoami op 08-02-2019 11:34 ]

[Rolandow]

Bedankt oZy. Je noemt een paar tools die ik nog niet ken, met name MaterialDesignInXaml en Dragablz. De web applicatie of apps laat ik voor nu even liggen. Ik denk bijvoorbeeld dat de stap naar Xamarin ook niet groot zal zijn als we al met WPF werken.

Ook IdentityServer klinkt goed. Persoonlijk hou ik meer van Linux, dus ik heb niet zoveel kaas gegeten van Active Directory en dergelijke. Ik weet wel dat dit nu bij ons lokaal draait. Office365 en AzureAD klinkt als cloud. Dus ik zal onderzoeken of die IdentityServer4 ook on premise kan.

Dit zijn wel een beetje de dingen waar ik naar op zoek was denk ik.

[Rolandow]

whoami schreef op vrijdag 8 februari 2019 @ 11:20:
Ik blijf het maar vreemd vinden dat er opeens allerhande technologiën worden voorgesteld zonder dat de scope en requirements gekend zijn. Iedereen spuit hier natuurlijk zijn eigen favoriete / gekende tools / technieken.

Ik zie hier bv CQRS voorbijkomen; allemaal mooi en leuk, maar is dat wel nodig ? Je weet het momenteel niet of het nuttig is of enkel extra complexiteit zal toevoegen.

Dit is natuurlijk ook een brede vraag van de TS, en ik denk dat die eerst de scope & requirements moet vastleggen.

Klopt, mijn vraag was erg breed. Het is ook gewoon heel veel om te beschrijven allemaal. De vraag was eigenlijk ook om een sparrings partner, eigenlijk niet om het probleem hier nu direct op te lossen. Het is denk ik te complex om dit via een forum te gaan regelen. Desalniettemin heb ik er toch wel een hoop uit kunnen halen.

whoami schreef op vrijdag 8 februari 2019 @ 11:20:
Een aantal zaken die ik hier zie voorbijkomen zijn dan wel weer goede guidelines:
- UI & backend opsplitsen zodanig dat je later een extra UI interface kunt toevoegen
- van in het begin gebruik maken van CI / CD

Zowiezo moet je ook eerst eens gaan nadenken over hoe je wil overstappen. Wil je een 'big bang' doen, waarbij er op een dag gezegd wordt. Kijk, vanaf dag x gaan we met het nieuwe systeem werken, waarbij je over het weekend bv alle bestaande data converteert naar het nieuwe systeem, of wil je gefaseerd gaan werken (zoek eens op strangler pattern).

Zeker goede guidelines! Die hadden ook wel bedacht. Maar gezegd is makkelijker dan gedaan. Het stuk 'gedaan' zou ik graag eens overleggen. Zien hoe een ander dit heeft gedaan. Overleggen op welk pad we zelf zitten. Dat werk ..

We kunnen helaas niet gefaseerd over, althans, ik denk dat het moeilijk wordt. Omdat ook de backend volledig verandert, kunnen we niet met de oude en nieuwe applicatie uit dezelfde data putten. Het is echter wel de bedoeling om ook de data migratie (conversie scripts dus) te maken, zodat onderdelen die af zijn, wel getest kunnen worden. Na verloop van tijd is er misschien genoeg in de nieuwe applicatie, waardoor we dit 'afgeschermd' kunnen noemen. Maar eigenlijk is alles verweven met elkaar, dus ik betwijfel of dat lukt.

Dat het hele bedrijf over gaat zal dus een soort 'big bang' worden. Maar er zal wel eerder feedback uit het veld komen, en we kunnen dus wel per deel programma zien of dit lekker samen werkt. Kwestie van uitproberen of het nieuwe pakket hetzelfde werkt als het oude, met 'echte' data die we geconverteerd hebben.

[ocf81]

@Rolandow Het lijkt me een hele opgave om zoiets te doen. Komt wel een beetje watervallerig over. Hoe borg je dan de risico's zonder een enorme overhead?

In ieder geval succes met zo'n zware opgave!

[Rolandow]

ocf81 schreef op vrijdag 8 februari 2019 @ 11:39:
@Rolandow Het lijkt me een hele opgave om zoiets te doen. Komt wel een beetje watervallerig over. Hoe borg je dan de risico's zonder een enorme overhead?

In ieder geval succes met zo'n zware opgave!

Het is inderdaad ook watervallerig. Ik zie ook niet hoe het anders zou kunnen. Behalve dan als we de huidige applicatie open breken zodat de nieuwe applicatie daar dingen uit kan halen?

Als de oude applicatie nou op een database zou draaien die gewoon benaderbaar is, dan zou je hier nog iets mee kunnen, en inderdaad dat strangler pattern kunnen gebruiken (als ik het goed begrepen heb). We kunnen dan onderdeel voor onderdeel vernieuwen.

Maar niet alleen is de database lastige benaderbaar; het is ook nog eens een ander type. Het is een multi value database. Had ik tot twee jaar geleden ook nog nooit van gehoord. Je kunt er dan bijvoorbeeld voor kiezen om een adres van een persoon op te slaan binnen het record van die persoon. Dus je hebt een veld "adressen", en dit veld is weer onderverdeeld in velden (vandaar multi value). Heel veel data zal dus qua structuur ook anders opgeslagen gaan worden. Het gaat dan wel erg veel moeite kosten om die data te porteren naar de nieuwe, relationele, opslag.

Dus ja, het wordt watervallerig. Maar wel watervallerig per onderdeel. Dus we gaan niet in 1 keer de hele applicatie proberen te documenteren en uit te zoeken, maar eerst het stuk relatie beheer. Dan project beheer. Dan uren registratie. Dan facturatie. Enz. enz.

Risico borgen is dan ook lastig; maar op zich is er al eens met het bijltje gehakt. De problemen die opgelost moesten worden zijn allemaal al eens opgelost. Er is nu juist een goed beeld van oplossingen die achteraf toch niet zo lekker werken, en we dus anders moeten gaan doen.

[oZy]

Rolandow schreef op vrijdag 8 februari 2019 @ 11:24:
Ik denk bijvoorbeeld dat de stap naar Xamarin ook niet groot zal zijn als we al met WPF werken.

zolang je de data/ui loskoppelt is dat vanzelfsprekend. Je moet je afvragen waarom je Xamarin nodig zou hebben als je puur bezig bent met het verwerken van data. Een SPA leent zich daar m.i. veel beter voor.

Ook IdentityServer klinkt goed. Persoonlijk hou ik meer van Linux, dus ik heb niet zoveel kaas gegeten van Active Directory en dergelijke. Ik weet wel dat dit nu bij ons lokaal draait. Office365 en AzureAD klinkt als cloud. Dus ik zal onderzoeken of die IdentityServer4 ook on premise kan.

Uiteraard kan dat on-premise, het is een npm package voor aspnetcore. Je kunt het zelfs op je Linux omgeving hosten als je dat zou willen Als je een enigszins moderne AD server hebt kun je deze uitbreiden met ADFS en dat tbv SSO gebruiken vanuit IdentityServer4.

[Killah_Priest]

. Ik heb n3n

[Yucon]

Disclaimer: ik ben geen developer. Niet meer tenminste, dus wat pure dev technieken niet meer echt up to date en daarom heb ik het topic niet tot op de laatste letter gelezen.

Maar vanuit architectuuroogpunt heb ik toch een opmerking. Wat ik met langscrollen zie is dat je de keuze meent te hebben tussen zelf ontwikkelen of een erp pakket kopen en daar maatwerk in bouwen. Zelf zijn we op dit moment met een tussenweg bezig. Het uitgangspunt is vanilla AX en daaromheen komt een schil van kleine apps waar ook wat aanvullend maatwerk in zit. Dit lijkt een hele sterke combi te zijn. Je lift namelijk mee op een standaard product met bijbehorende business logic en op punten waar dat teveel wringt kun je vrij eenvoudig ingrijpen in die apps zonder dat je ook nog eens zelf de hele business logic moet bouwen.

Misschien is het de moeite waard om die optie eens te overwegen.

[ Voor 4% gewijzigd door Yucon op 09-02-2019 13:16 ]

[HotCool2]

Zoveel ontwikkelaars, zoveel meningen :-)

In 2014 heb ik een WPF client/server applicatie opgezet (met SQL Server als database). Sindsdien doe ik het onderhoud. Concurrency en SQL Server performance blijven uitdagingen, maar de applicatie draait stabiel en is in mijn ogen goed onderhoudbaar.

Dit zijn de gebruikte technieken: Enterprise Architect voor database ontwerp. LLBLgen als ORM tool. Plain vanilla WPF/MVVM met Telerik (voornamelijk voor grids) en AvalonDock en WCF voor calls naar de business service layer.

Succes met je project.

[Hydra]

Rolandow schreef op vrijdag 8 februari 2019 @ 11:34:
Zeker goede guidelines! Die hadden ook wel bedacht. Maar gezegd is makkelijker dan gedaan. Het stuk 'gedaan' zou ik graag eens overleggen. Zien hoe een ander dit heeft gedaan. Overleggen op welk pad we zelf zitten. Dat werk ..

https://www.joelonsoftwar...u-should-never-do-part-i/

Interessant verhaal over waarom je weinig verhalen over succesvolle rewrites tegen komt.

Hoe dan ook; jouw idee om 'big bang' over te gaan, gaat niet werken. In de meeste gevallen wordt het strangler pattern toegepast. Ook met dat soort legacy applicaties.

[Rolandow]

@HotCool2 Thanks, ik ga die tools onderzoeken.

Dat artikel van Joel heb ik ook al een paar keer gelezen. Groot verschil is wel dat wij niet ontwikkelen voor derden maar alleen voor onszelf. Het argument hier is dat Netscape de boot gemist heeft omdat ze te lang bezig waren met het herschrijven van hun applicatie. Dat speelt bij ons niet.

Hoe dan ook; jouw idee om 'big bang' over te gaan, gaat niet werken.

Want? Ik lees geen onderbouwing.

Zoals ik al schreef, het strangler pattern gaat juist niet werken. De nieuwe applicatie kan de data van de oude niet benaderen. Aangezien bijna alles van elkaar afhankelijk is, gaat het niet werken om deels in de nieuwe, en deels in de oude applicatie te werken. Mochten we op een punt komen waar dit wel mogelijk is, dan gaan we dit zeker toepassen.

[Rolandow]

In algemenere zin; we hebben inmiddels een partij gevonden die een combinatie van consultancy en training geeft. Als dat allemaal waar blijkt te zijn, dan wil dat zeggen dat we samen de basis gaan opzetten, maar dat het doel voornamelijk is om ons te trainen. Dit voorkomt een lock-in, maar zorgt er wel voor dat we goede begeleiding krijgen.

Ik ben erg benieuwd wat dat zal opleveren, maar ik denk dat het ervoor zorgt dat het proces enorm versneld wordt.

[Verwijderd]

Rolandow schreef op dinsdag 5 februari 2019 @ 15:17:
[...]


Nou nee, meer omdat er meer mensen zijn die deze gedachtegang volgen.

Met projecten van deze omvang is het altijd koffiedik kijken denk ik. Er zijn veel voorbeelden van grote software fabrikanten die steeds meer geld gaan vragen voor maatwerk, maar er zijn ook verhalen van bedrijven die alles zelf doen en vervolgens met een systeem zitten dat incompatibel of slecht onderhoudbaar is.

Er is tegenwoordig ook een derde variant, precies in het midden. Genaamd: « low code »

Hiermee kan je als het ware je eigen applicatie bij elkaar configureren, maar heb je nog wel technische kennis nodig om bijvoorbeeld koppelingen met andere systemen op te zetten

Filmpje over wat «loe code» is

YouTube: What is Low Code?

Voorbeeld van low code applicatieontwikkeling met OutSystems:

YouTube: Build a Web Responsive App With OutSystems in Minutes

Zou dit mogelijk wat voor jullie zijn?

[ Voor 11% gewijzigd door Verwijderd op 10-02-2019 13:09 ]

[Rolandow]

Yes, hebben we ook naar gekeken. Maar de licentiekosten zouden dan veel te hoog worden. Je hebt ook Thinkwise, dat is ook lowcode, maar daarbij wordt je ook flink ondersteund in de ontwikkeling. Op zich heel mooi, maar wel erg duur.

[Verwijderd]

Als je voor low code gaat moet he de licentiekosten niet op zichzelf beoordelen. Het zijn de kosten van IT developers wasr je op bespaart.

Outsystems kost bijvoorbeeld een vast bedrag per maand. Als je daardoor je IT ontwikkeling met 1-2 minder developers kan doen is het al terugverdiend.

Maar deze beslissing gaat nooit door een ITer gemaakt worden (eigen vlees), dat moet echt de business doen.

[epic007]

oZy schreef op vrijdag 8 februari 2019 @ 10:53:
...

• .NET is een prima platform waarin je alle aangedragen architectuuropties kwijt kunt
• De echte winst in dit project ligt in het database ontwerp + kans om modellen opnieuw te definiëren
• Nadrukkelijk advies om data/ui te scheiden dmv een api.
• Gebruik een centraal Identity platform voor het regelen van de authenticatie / autorisatie
• Als het echt in een desktop applicatie moet is WPF + MVVM een prima systeem

...

+1

@Rolandow als ik je voorgaan de reacties zo even leest ben jezelf erg met de front-end kant van de applicatie bezig (Keuze WPF, Forms, Web etc). Is je huidige applicatie echt zo UI heavy? Of is het meer back-end heavy?
Ik zou eens goed naar je huidige applicatie kijken en onderzoeken waar nu de meeste effort in heeft gezeten (presentatielayer, datalayer, business logic).

Verder is scheiding van UI en back-end inderdaad echt aan te raden. Denk vanuit een API die de UI gaat gebruiken. Ik bouw mijn applicaties altijd eerst vanuit een console-app en bouw daar later een UI omheen.

En lees eens wat over Domain Driven Design (DDD). Dit heeft mij erg geholpen bij het opzetten van 'grote' software.

[Rolandow]

Het is meer backend heavy. Het uiterlijk is van ondergeschikt belang, maar het leek me wel zinvol om de meest recent mogelijke technieken te kiezen. UWP valt af, dus dan zou daarna WPF komen. De enige reden om niet voor WPF te kiezen zou, volgens mij, zijn dat het lastiger is om te leren, en wat meer werk om hier iets in te maken. Maar als dat alles is, dan nemen we dat wel voor lief :-)

Waar heb je over DDD gelezen? In een boek? Online? Welke bron heeft je het meest geholpen?

[epic007]

Een aantal cursussen op pluralsight waren erg verhelderend:

https://www.pluralsight.c...riven-design-fundamentals
https://www.pluralsight.c...driven-design-in-practice
https://www.pluralsight.c...en-design-legacy-projects

Rolandow schreef op maandag 11 februari 2019 @ 15:31:
Het is meer backend heavy. Het uiterlijk is van ondergeschikt belang, maar het leek me wel zinvol om de meest recent mogelijke technieken te kiezen. UWP valt af, dus dan zou daarna WPF komen. De enige reden om niet voor WPF te kiezen zou, volgens mij, zijn dat het lastiger is om te leren, en wat meer werk om hier iets in te maken. Maar als dat alles is, dan nemen we dat wel voor lief :-)

Ik zou je keuze voor de tooling nu even naar achter schuiven en je richten op wat de applicatie daadwerkelijk moet gaat doen. Wat is het datamodel? Wat zijn de requirements / use cases?

Daarom is bijvoorbeeld het Repository pattern wel weer bruikbaar, omdat je dan nog niet vastlegd welke ORM je gaat gebruiken (Entity framework, plain SQL? of iets anders?). Je kan deze keuze dan ook nog even voor je uitschuiven.

[ Voor 62% gewijzigd door epic007 op 11-02-2019 16:10 ]

[Eeki]

Rolandow schreef op maandag 11 februari 2019 @ 15:31:
UWP valt af, dus dan zou daarna WPF komen.

Ben benieuw wat de overwegingen zijn om WPF te verkiezen boven UWP. De WPF controls die gebruikt kunnen worden zijn nagenoeg allemaal aanwezig in UWP. Er zijn inderdaad restricties in UWP (zoals geen onbeperkt toegang tot het hele filesysteem en toegang tot registry), maar die heb je waarschijnlijk niet nodig als de app een database backend heeft voor de data. Een UWP app hoeft niet vanuit een store te worden gedeployed zoals eerder in dit topic is aangegeven. Er zijn dus nogal wat aannames over UWP die misschien een paar jaar geleden golden, maar nu niet meer. UWP heeft voordelen. Het draait namelijk op alle nieuwe Windows devices en heeft geen desktop profiel nodig (itt WPF), dus Windows Hub, HoloLens, etc. Daarnaast zijn er pogingen om UWP applicaties in een browser te laten draaien mbv het UNO platform icm webassembly.

Maw WPF kan, maar waarom niet UWP. Qua talen (XAML, C#) en design patterns (databinding en MVVM), erg vergelijkbaar, maar UWP denk ik meer toekomstbestending. WinForms raad ik sowieso af voor een greenfield project, omdat het geen databinding ondersteunt.

[Rolandow]

@Eeki Er is natuurlijk altijd een kans dat ik verkeerd geinformeerd ben, dat voorop gesteld :-). Maar als ik naar deze vergelijking kijk zijn de redenen:

- UWP support geen windows 7. Dat hoeft niet perse een probleem te zijn, omdat tegen de tijd dat we klaar zijn, iedereen waarschijnlijk wel Windows 10 heeft. Op dit moment is dat echter niet zo.
- In deze vergelijking staat volgens mij dat de app store nodig is. Dat willen we niet. Maar als jij zegt dat dit inmiddels niet meer zo is, valt dit argument af.
- File system hebben we nu juist wel nodig. Er is een eigen document beheer systeem gemaakt, waarbij voor de opslag gewoon file shares worden gebruikt. Nu hoor ik mensen al roepen dat dit waarschijnlijk niet de juiste manier is om dit te doen, maar ik heb niet de intentie om meteen de wereld te verbeteren zeg maar ;-). Dus ook om backwards compatible te zijn met ons huidige DMS, denk ik dat dit juist wel belangrijk is.

Verder heeft UWP eigenlijk niet zo zeer een meerwaarde waar wij gebruik van gaan maken.

[sig69]

Eeki schreef op dinsdag 12 februari 2019 @ 09:27:
[...]

WinForms raad ik sowieso af voor een greenfield project, omdat het geen databinding ondersteunt.

https://docs.microsoft.co...indows-forms-data-binding

[Eeki]

Er is geen store nodig, een app is te sideloaden, ofwel via een appx bestand of nu via msix. Ik meen dat WPF ook te deployen zal zijn via het nieuwe msix model.

Dat winfoms ook databinding ondersteund, wist ik niet. Na een eerste scan lijkt mij dat het iets meer werk is om dit mogelijk te maken dan het gebruiken van databinding via XAML.

[Alex)]

Rolandow schreef op dinsdag 12 februari 2019 @ 17:11:

UWP support geen windows 7. Dat hoeft niet perse een probleem te zijn, omdat tegen de tijd dat we klaar zijn, iedereen waarschijnlijk wel Windows 10 heeft. Op dit moment is dat echter niet zo.

Windows 7 loopt over 11 maanden uit de officiële support. Ik mag hopen dat jullie IT-afdeling tegen die tijd toch wel klaar is met een migratie naar Windows 10

[Rolandow]

Dat hoop ik ook Alex, maar ik ben geen IT-afdeling dus daar bemoei ik me lekker niet mee ;-)

[Alex)]

Over de distributie via de Microsoft Store: in de Store kun je een eigen tabje krijgen voor jullie bedrijf, waar je de nieuwe app dan kunt publishen. Je collega's kunnen de app dan downloaden via de MS Store, ook de verspreiding van updates loopt dan via Microsoft.

Gebruik van de Microsoft Store is niet beperkt tot UWP, dankzij Desktop Bridge kun je ook apps 'repackagen' naar het appx-formaat en verspreiden.

[Gomez12]

Eeki schreef op dinsdag 12 februari 2019 @ 09:27:
[...]
Maw WPF kan, maar waarom niet UWP. Qua talen (XAML, C#) en design patterns (databinding en MVVM), erg vergelijkbaar, maar UWP denk ik meer toekomstbestending. WinForms raad ik sowieso af voor een greenfield project, omdat het geen databinding ondersteunt.

Ik vermoed toch dat van UWP / WPF / Winforms, Winforms het meest toekomstbestendig is.

WPF staat al een tijdlang stil.
UWP is een "nieuw iets" en MS is de laatste xx jaar niet goed meer met nieuwe dingen, qua UWP hebben ze ook alweer afscheid genomen van een gigantische doelgroep, namelijk telefoons... Terwijl telefoons wereldwijd nog steeds meer en meer desktops verdringen.
Ook tablets heeft MS zo goed als afscheid van genomen...
Qua devices die UWP ondersteunen zitten ze bijna alleen nog maar op de desktop en laptops (of je moet je apps ook op xbox willen draaien) en op de desktop is UWP juist weer kunstmatig beperkt zodat de mogelijkheden weer meer richting web / mobile apps gaan.
En voor mobile hebben ze weer Xamarin wat slechts gedeeltelijk UWP doet en je kan niet en Xamarin upgraden en UWP uitbreiden.
En qua web, tja daar gaat UWP nooit iets doen net zomin als het multiplatform iets zal doen.

UWP is wmb dan ook een soort van beperkte WPF 2.0. En WPF heeft niet zonder reden jaren stilgelegen. En toekomstig hebben ze hun eigen markt al kunstmatig beperkt (alhoewel het nog steeds een gigantische markt blijft is hij wel simpelweg gelimiteerd)

En wat dan voor WinForms praat, MS heeft altijd heel veel aan backwards compatibility gehangen en als er ergens veel programma's in geschreven zijn (en worden). Je hebt heden ten dage nog steeds programmeurs die alleen in MS-programma's programmeren en alleen maar de beschikking over winforms hebben (office automation bijv). En dan praat je nog niet eens over alle programmeurs die niet over MS-programmeertools beschikken (ik ken nog steeds Delphi programmeurs die werk hebben).
Zie ook wat ze met ARM-processoren doen, je kan ervoor compileren, maar voorlopig draait je x86-software gewoon op ARM via onderhuidse emulatie.

Oftewel WinForms zie ik nog niet weg gaan omdat het simpelweg nog steeds de meest volledige UI is en omdat ik MS nergens echt zijn macht achter zie zetten om het te vervangen, het zijn allemaal kleine experimentjes wat ze uitvoeren maar niet echt iets groots.

Maar wat voor TS het meest belangrijke is : Winforms / WPF / UWP het is "slechts" de UI, scheid je logica en UI goed en duidelijk en je hele backend in c# gemaakt kan gerust wel 20 jaar meegaan terwijl je mogelijk wel je UI 3 of 4x moet vervangen in die tijd.

[s006110]

@Gomez12 Ik moet zeggen dat ik dat een duidelijk betoog vind! Ik zelf geef ook de voorkeur aan winforms, vooral om dat het en stuk laagdrempeliger is. Uwp heb ik net zoals jou weinig vertrouwen is als nieuwe standaard, omdat Windows Phone een stille dood gestorven is. Als tweede standaard, voor het ontwikkelen voor hololens en xbox.

[Gomez12]

s006110 schreef op donderdag 14 februari 2019 @ 18:19:
Ik zelf geef ook de voorkeur aan winforms, vooral om dat het en stuk laagdrempeliger is.

Begrijp me niet verkeerd, maar ik heb een gruwelijke hekel aan winforms en zal er alleen iets mee doen voor office automation oid.
Ikzelf geef momenteel het meest de voorkeur aan web en daarna WPF voor UI werk.
Ik beschouw mezelf als programmeur en niet designer oftewel ik maak een backend, een API om die te benaderen en de UI is voor mij veelal slechts een API-reference implementatie om mee te testen etc.

Meeste klanten adviseer ik ook om gewoon een andere programmeur/designer in te huren voor de UI. Het is gewoon niet mijn ding, alleen ik moet om het te kunnen testen / bewijzen dat het werkt iets kunnen opleveren.
Praktisch gezien ga ik er wel vanuit dat mijn UI-implementatie na max 2 of 3 jaar aan de kant gemieterd wordt waardoor ik niet ga nadenken over de langere termijn van de UI.

Echter TS wil ook voor de langere termijn een UI-keuze maken als ik het goed begrijp en tja dan zou ik waarschijnlijk op safe spelen en voor winforms gaan.
Alleen maak niet de denkfout dat ik een voorkeur of iets heb voor winforms. Ik blijf het een gruwel-platform vinden en zo ongeveer elk ander framework heb ik liever

[Lethalis]

Gomez12 schreef op donderdag 14 februari 2019 @ 22:12:
[...]
Echter TS wil ook voor de langere termijn een UI-keuze maken als ik het goed begrijp en tja dan zou ik waarschijnlijk op safe spelen en voor winforms gaan.
Alleen maak niet de denkfout dat ik een voorkeur of iets heb voor winforms. Ik blijf het een gruwel-platform vinden en zo ongeveer elk ander framework heb ik liever

Dit topic is 1 van de velen op internet en dat is Microsoft zijn eigen schuld.

Simpel antwoord: er is geen lange termijn visie voor de UI van Windows.

Daarom is er ook geen enkele Windows UI toolkit / framework waar je voor de lange termijn op kunt bouwen.

Windows Forms heeft alleen het voordeel dat er zo verschrikkelijk veel legacy apps op draaien dat Microsoft het zich niet kan veroorloven om het niet meer te ondersteunen (al is het maar de vraag hoe je "het open sourcen" ervan kunt zien, je kunt het ook zien als "hier leef je uit, wij doen er iig niks meer aan nu").

Als iets echt voor langere tijd moet blijven werken, dan zou ik vrijwel altijd voor een user interface gaan die gebaseerd is op web technieken. De kans dat browsers over 10 jaar jouw HTML, CSS en JavaScript nog kunnen begrijpen is een stuk groter dan dat Windows Forms het dan nog doet, laat staan dat Windows dan nog het besturingssysteem is dat iedereen gebruikt.

Ofwel omdat Microsoft tegen die tijd met een nieuw OS komt, ofwel omdat we allemaal gewend zijn aan convertibles gebaseerd op mobiele OS-en, Chromebookjes, etc.

Sta je dan met je Windows Forms app. Die kan dan zo de prullenbak in.

Bouw je echter een webapplicatie dan kan iedereen die nog steeds gebruiken straks vanaf wat voor wazig apparaat er dan wel niet is. Maar een gewone computer is het waarschijnlijk niet meer

Op mijn werk zitten we met 2 enorme Windows Forms applicaties en we hopen ze beide naar een webapplicatie te krijgen in de toekomst. Doen we dat niet, of zijn er daar straks te laat mee, dan zie ik het behoorlijk somber in (uiteraard heb ik wel in mezelf geïnvesteerd en kan ik prima een Angular web applicatie bouwen met een REST API erachter... I'll survive).

[ Voor 3% gewijzigd door Lethalis op 15-02-2019 10:13 ]

[Defector]

Waarom niet best of both worlds? Standaard ERP pakket en dan het specifieke maatwerk apart via web-services of geïntegreerd. Kijk bijvoorbeeld eens naar OpenERP of als je in de Microsoft hoek wil blijven. Dynamics AX. Maatwerk is gewoon onderdeel van die pakketten.

Dan heb je als voordeel dat je een basis hebt waarin de werkwijze al vastligt. Techstack, wijze van uitbreiden, best practices etc. Daarnaast zijn de standaard functionele processen al gewaarborgd. Dus je hoeft niet het wiel opnieuw uit te vinden. En je bent snel op and running met de standaard zaken.

Verder heb je op het vlak van continuïteit ook voordelen aangezien er genoeg bedrijven zijn die consultancy of ontwikkelaars beschikbaar hebben. Dus als er uitval is of er nieuwe collega's gezocht worden dan is dat ook geen probleem.

[Gomez12]

Defector schreef op vrijdag 15 februari 2019 @ 11:21:
Waarom niet best of both worlds? Standaard ERP pakket en dan het specifieke maatwerk apart via web-services of geïntegreerd. Kijk bijvoorbeeld eens naar OpenERP of als je in de Microsoft hoek wil blijven. Dynamics AX. Maatwerk is gewoon onderdeel van die pakketten.

OpenERP ken ik niet, maar AX daar wil je als bedrijf praktisch geen maatwerk voor hebben.

Het voordeel van een standaard erp-pakket is over het algemeen dat je "gratis" mee kan gaan met de ontwikkelingen van de leverancier. Oftewel als er in AX 2020 virtual screens en gratis bitcoin generatoren gebouwd worden dat je die gratis meekrijgt als bedrijf.

Alleen de praktijk die ik veelvuldig / bijna altijd zie bij AX is dat er zoveel maatwerk is dat er niet meer naar een nieuwe versie gegaan kan worden vanwege het maatwerk.
En dan heb je dus bedrijven die heden ten dage nog op AX 2012 oid zitten en heel graag over willen naar de nieuwe versie maar het niet kunnen qua maatwerk.

Ik ken ietwat te veel AX implementaties waarbij het overzetten / controleren / nalopen van het maatwerk geschat wordt op minimaal het 10-voudige qua kosten dan een daadwerkelijke overgang en met elke nieuwe AX-versie wordt die kostenpost hoger omdat de verschillen groter worden.

Maatwerk is leuk voor als je echt iets aparts hebt wat totaal niet in AX zit en echt een toevoeging is.
Alleen maatwerk wordt veelal misbruikt om te pogen AX te vormen naar de wens van het bedrijf en dan loop je vast. Met iets als AX moet je bedrijf zich aanpassen en niet AX.

[Defector]

Gomez12 schreef op vrijdag 15 februari 2019 @ 11:57:
[...]

OpenERP ken ik niet, maar AX daar wil je als bedrijf praktisch geen maatwerk voor hebben.

Het voordeel van een standaard erp-pakket is over het algemeen dat je "gratis" mee kan gaan met de ontwikkelingen van de leverancier. Oftewel als er in AX 2020 virtual screens en gratis bitcoin generatoren gebouwd worden dat je die gratis meekrijgt als bedrijf.

Alleen de praktijk die ik veelvuldig / bijna altijd zie bij AX is dat er zoveel maatwerk is dat er niet meer naar een nieuwe versie gegaan kan worden vanwege het maatwerk.
En dan heb je dus bedrijven die heden ten dage nog op AX 2012 oid zitten en heel graag over willen naar de nieuwe versie maar het niet kunnen qua maatwerk.

Ik ken ietwat te veel AX implementaties waarbij het overzetten / controleren / nalopen van het maatwerk geschat wordt op minimaal het 10-voudige qua kosten dan een daadwerkelijke overgang en met elke nieuwe AX-versie wordt die kostenpost hoger omdat de verschillen groter worden.

Maatwerk is leuk voor als je echt iets aparts hebt wat totaal niet in AX zit en echt een toevoeging is.
Alleen maatwerk wordt veelal misbruikt om te pogen AX te vormen naar de wens van het bedrijf en dan loop je vast. Met iets als AX moet je bedrijf zich aanpassen en niet AX.

Dat is inderdaad een valkuil waar je in kan stappen. Maar dat kan je van alle software integratie/ontwikkelingen zeggen. Er zijn menig software implementatie/ontwikkel projecten verknald omdat geen goede sturing was of een stevige projectmanager die alles goed in de hand houdt.

Kijk als je ontwikkellaars en eindgebruikers een vrijbrief geeft, dan weet je zeker dat je met een draak van een product komt te zitten. En dan maakt het niet uit of je C#/Java/SAP/Dynamics AX gebruikt

Je noemt Dynamics 2012 maar daar kan je juist heel goed het maatwerk scheiden van de standaard dmv modellen en lagen. Of compleet buiten Dynamics AX 2012 om met web-services. Maar goed zoals ik al zei bij elke aanpak kan je het goed en fout doen.

[farlane]

Lethalis schreef op vrijdag 15 februari 2019 @ 10:10:
[...]
Als iets echt voor langere tijd moet blijven werken, dan zou ik vrijwel altijd voor een user interface gaan die gebaseerd is op web technieken.

Sorry hoor maar als er iets short lived is dan is het wel iets wat voor het web gemaakt is. Het mag dan misschien wel "blijven werken", maar in de praktijk zul je ook daar eens in de zoveel tijd je spul moeten vernieuwen.

Ik vermoed dat een WinForms applicatie voor .NET 1.0 nu ook nog draait op Windows....

[Lethalis]

farlane schreef op vrijdag 15 februari 2019 @ 14:28:
[...]
Sorry hoor maar als er iets short lived is dan is het wel iets wat voor het web gemaakt is.

Nee hoor, dat hangt helemaal van jezelf af.

Je kunt inderdaad elke keer met de nieuwste hype mee qua libraries en frameworks, maar dat hoeft niet.

Als jij 5 jaar geleden iets met jQuery hebt gebouwd, werkt het vandaag ook nog perfect. En als je het netjes hebt opgezet, hoeft het niet eens zo'n drama te zijn om te onderhouden.

Natuurlijk is het veel leuker om Angular te gebruiken. Als Google dan volgend jaar weer met iets anders komt, ligt dat echter niet aan "het web", maar gewoon aan Google. AngularJS doet het immers ook nog steeds prima.

Je zal dus conservatief moeten zijn met het kiezen van libraries, maar dat geldt in principe altijd.

Ik denk alleen wel dat we een toekomst tegemoet gaan die steeds meer op het web leunt. Dat merk ik ook op mijn werk. Hoe vaak komt het wel niet voor dat een klant met zijn iMac, iPad, Android tablet, Chromebook, weet ik wat gebruik wil maken van onze ERP software die Windows only is, en nog op afstand ook.

Dat gaat op den duur een probleem worden. De concurrentie komt ook met web applicaties.

Daar kan je je (tevergeefs) tegen verzetten, of je kunt het omarmen.

[farlane]

Lethalis schreef op vrijdag 15 februari 2019 @ 14:44:
Daar kan je je (tevergeefs) tegen verzetten, of je kunt het omarmen.

Het is niet zo dat ik me er tegen verzet, maar wat je nu ontwikkelt voor het web gaat echt niet over 10 jaar nog lekker passen in de stijl van die tijd.

[ocf81]

Wat je wel merkt is dat er steeds weer dingen qua HTML en javascript worden gedeprecate waardoor je toch weer onderhoud moet plegen om met de nieuwste browsers mee te kunnen. De basis blijft wel, maar allerlei minder algemene zaken veranderen continu.

[NicoJuicy]

Op mijn vorig werk, bestond de ERP-applicatie uit vb6 + access.

Zelf grotendeels geconverteerd naar Asp.Net MVC ( op aandringen van de baas), maar ik had het deels anders gedaan.

C# is wel een stabiele keuze voor de toekomst. Kan ik je ergens bereiken?