[JS/C#]Duplicerende logica client en serverside voorkomen

[Razr]

Scenario:
In een web applicatie heb je een pagina om een product aan het systeem toe te voegen (of te bewerken). Deze pagina toont alle velden van het entiteit product. Alles is zoveel mogelijk cliënt side georiënteerd d.m.v. KnockoutJS – dit werkt allemaal prima, mooie MVVM structuur. Alleen de geserializeerde view modellen (JSON) worden heen en weer gestuurd (WebAPI).

Huidig:
Op dit moment gaan alle berekeningen client side, in JS / het view model. Stel er zijn vier velden, laten we zeggen veld A t/m D. Het kan zo zijn dat als je in veld A wat intypt, velden B t/m D gelijk herrekend worden. De herreken formule is afhankelijk van meerdere velden van de entiteit. Dit werkt allemaal goed, met ‘keyup’ events wordt alles gelijk herrekend en bijgewerkt.

Probleem:
Nu komt dus dat we ook server-side de mogelijkheid willen gaan maken om daar alles te herrekenen. Het kan nu namelijk zo zijn dat we (via een gepland process/CRON) een update krijgen van een leverancier waardoor bij een X aantal producten veld A opeens veranderd van waarde. Dan moeten we ook aan de server kant de andere velden (B t/m D) kunnen herrekenen.

Op dit moment zie ik eigenlijk twee manieren waarop we dit kunnen doen:

1. We dupliceren de (JS) logica om de waarden te berekenen ook server side. Dit is natuurlijk een mega nadeel voor maintainability.
2. Alle reken logica verhuist naar de server. Maar dat zou betekenen dat zodra een gebruiker een waarde veranderd (JS ‘keyup’ event momenteel) we direct het hele view model naar de server moeten posten, de server het model herrekend en deze vervolgens weer retourneert. Dit heeft natuurlijk een nadeel dat de applicatie duidelijk snelheid inlevert. Sowieso denk ik dat je in plaats van een ‘keyup’ dan eerder naar een ‘changed’ event moet gaan kijken. Vooral dat laatste is iets wat we eigenlijk niet willen.

Wat is jullie advies in deze? Of zijn er nog andere mogelijkheden die ik kan overwegen? Let op dat ik hier vier velden als voorbeeld gaf, maar in de praktijk kunnen het er tientallen zijn.

[UltimateB]

Op dit moment zal je toch ook de server side data moeten verifieren. Je kan data die van de client komt in geen enkel geval vertrouwen. Nu zou je de kantjes eraf kunnen lopen aangezien het om een afgeschermd deel gaat neem ik aan. Maar als je het goed wilt doen moet je toch echt de server side data ook verifieren.

Ik denk dat hier de integriteit van de data toch echt belangrijk is. En dan moet je serverside verifieren helaas.

[pedorus]

Op zich kun je serverside ook prima javascript draaien, met node.js of http://javascriptdotnet.codeplex.com/ bijvoorbeeld. Je geeft wat (te) weinig informatie over het type applicatie en de functionele eisen om verder wat zinnigs te zeggen, maar over het algemeen is het natuurlijk logisch om server-side de business logica te hebben.

[Razr]

UltimateB schreef op zaterdag 21 september 2013 @ 15:51:
Op dit moment zal je toch ook de server side data moeten verifieren. Je kan data die van de client komt in geen enkel geval vertrouwen. Nu zou je de kantjes eraf kunnen lopen aangezien het om een afgeschermd deel gaat neem ik aan. Maar als je het goed wilt doen moet je toch echt de server side data ook verifieren.

Ik denk dat hier de integriteit van de data toch echt belangrijk is. En dan moet je serverside verifieren helaas.

Dat is ook waar ik heen wil, daarom post ik eigenlijk ook meer de vraag over hoe ik dat het beste kan doen. En dan met zaken als onderhoudbaarheid en snelheid in het achterhoofd (omdat dezelfde logica eigenlijk op twee plekken beschikbaar moet zijn).

pedorus schreef op zaterdag 21 september 2013 @ 15:59:
Op zich kun je serverside ook prima javascript draaien, met node.js of http://javascriptdotnet.codeplex.com/ bijvoorbeeld. Je geeft wat (te) weinig informatie over het type applicatie en de functionele eisen om verder wat zinnigs te zeggen, maar over het algemeen is het natuurlijk logisch om server-side de business logica te hebben.

Dat is een goede tip, ik ga daar eens wat meer over onderzoeken . Qua functionele eisen is het relevant om te weten dat de applicatie erg 'native' moet aanvoelen. Dus als je een toetsaanslag afvangt, het hele model herrekent en bijgewerkt wordt. Als je eerst op de server moet wachten tot deze het herrekende model retourneert gaat dat al snel blokkerend aanvoelen ben ik bang.

Eigenlijk is dat ook de reden dat de meeste van die logica nu in JS / clientside is, om zo snel het model te kunnen bijwerken na een wijziging.

[RobertMe]

Wat ik een keer heb gedaan is de logica opnemen in de server, logischerwijs, maar niet uitgewerkt als echte gecompilede code, maar als lambda expressions. Deze lambda expressions kun je at runtime weer compileren naar methodes die je gewoon kunt aanroepen (LambdaExpression.Compile / Expression<TDelegate>.Compile). Echter is een lambda expression een omschrijving van "iets". Deze kun je ontleden en omschrijven naar iets anders. In mijn (en jouw) geval kan dat dus KO zijn. Om deze ontleding te doen kun je gebruikmaken van de ExpressionVisitor. Je kunt dan dus (intern) een StringBuilder aanmaken en in elke Visit... method schrijf je het stukje benodigde KO code behorende tot die expression. In VisitBinary krijg je dan als voorbeeld dus iets als

C#:

this.Visit(node.Left);
switch(node.NodeType)
{
  case ExpressionType.Equal:
    _stringBuilder.Write(" = ");
    break;
}
this.Visit(node.Right);

Het voordeel van het gebruik van lambda expressions is ook dat deze compile time safe zijn. Wat de JS code natuurlijk nooit kan zijn omdat die logischerwijs niet gecompileerd is maar ook jouw (server side) business model niet kent.

[Guldan]

Wij hebben ook code gedupliceerd maar dmv http://linqjs.codeplex.com/ lijkt de linq code iig redelijk op elkaar. Daarnaast heb je toch altijd verschillen tussen C# en Js.

[BasieP]

Ten eerste wil ik zeggen dat het op twee plaatsen logica hebben ook een positieve kant heeft.
Je dwingt namelijk jezelf om de validatie logica op zo'n duidelijke manier te schrijven dat je de client kant en de serverkant makkelijk kunt vergelijken.
Een aparte .js file voor de controle, en een vergelijkbare .cs file bijvoorbeeld.


Toch snap ik dat je logica op 1 plek wilt.
Ik snap deze zin niet helemaal

dat je direct het hele view model naar de server moeten posten, de server het model herrekend en deze vervolgens weer retourneert.

Dat lijkt me een reden om niet voor dat framework te kiezen. Zeker in de wereld waarin we nu leven lijkt het me handig om dingen als loosly coupled en modulair programming serieus te nemen.
Dat wil zeggen dat je als je straks een veldje toevoegd om te valideren, je alleen dat veldje (of setje veldjes) over de lijn stuurt, en niet je hele view. Je kan dan namelijk ook tegen verschillende servers valideren (mits restfull) en je kunt parallel valideren.
Verder minimaliseer je de dataoverdracht, en heb je als gebruiker een responsive webpage


@RobertMe
prachtig mooi, maar je data moet dan toch nog steeds van de client naar de server? of kan je die lamda expressions in JS runnen? (ik snap je verhaal op dat vlak niet helemaal)

[ Voor 6% gewijzigd door BasieP op 23-09-2013 22:23 ]

[R4gnax]

BasieP schreef op maandag 23 september 2013 @ 22:20:
@RobertMe
prachtig mooi, maar je data moet dan toch nog steeds van de client naar de server? of kan je die lamda expressions in JS runnen? (ik snap je verhaal op dat vlak niet helemaal)

Mits de lambda expressies van redelijk simpele aard zijn kun je een eigen code generator schrijven die ze gebruikt om JavaScript code te outputten welk dan op zijn beurt de client-side validatie af zou moeten handelen.

Da's de theorie althans.

[pedorus]

Lijkt me niet iets wat je zelf moet gaan schrijven. Via http://stackoverflow.com/...n-tree-to-emit-javascript kwam ik op script#.

How do I use knockoutjs with ScriptSharp?
Share code between website/web application project and Script#/ScriptSharp

[Gomez12]

R4gnax schreef op maandag 23 september 2013 @ 23:48:
[...]


Mits de lambda expressies van redelijk simpele aard zijn kun je een eigen code generator schrijven die ze gebruikt om JavaScript code te outputten welk dan op zijn beurt de client-side validatie af zou moeten handelen.

Da's de theorie althans.

Klinkt mij toch erg in de oren als extreem overengineered en supertraag (om niet te spreken over foutgevoelig). In wezen ga je dus JS code produceren op de client die je daarna met iets als eval gaat uitvoeren?

[drm]

Dit is een typisch geval waar een domain specific language ("DSL") uitkomst kan bieden en m.i. op langere termijn ook de enige echt goede oplossing is. De taal zou kunnen compilen naar en/of geëvalueerd worden binnen verschillende talen.

Als je het eenmaal kan compilen naar JS is het compilen naar een andere taal een kleine stap. Het voordeel is dat je taal alleen maar precies dat ondersteunt wat de business logic nodig heeft en dus waarschijnlijk puur declaratief is, wat eenvoudig te begrijpen en bij te werken is voor degene die (veel) met de business logic te maken hebben. Het nadeel is dat je het risico loopt meer aan je taal te sleutelen dan aan je feitelijke implementatie, maar dat hangt af van de complexiteit van je business rules.

Desalniettemin erg leerzaam en de stap is minder groot dan je in eerste instantie zou denken, zeker als het (alleen) om berekeningen gaat. Een handmatige top-down parser/compiler schrijven voor rekensommetjes is namelijk best makkelijk en intuïtief, en anders zijn er tegenwoordig tal van parsergenerators voor allerlei platforms beschikbaar, dus ongetwijfeld ook voor C#.

Maar je moet zelf inschatten of dat inderdaad iets is waar je je in zou kunnen/willen verdiepen. Het vergt wel een bepaald abstractieniveau en het is niet in een uurtje gedaan.

[Biersteker]

Razr schreef op zaterdag 21 september 2013 @ 15:44:
Probleem:
Nu komt dus dat we ook server-side de mogelijkheid willen gaan maken om daar alles te herrekenen.

1. We dupliceren de (JS) logica om de waarden te berekenen ook server side.
2. Alle reken logica verhuist naar de server.

Hoeveel users gaat het om. Er ligt zeker waarde in om een gedeelte logica binnen een client te houden, zodat je de server ontlast voor simpel dom werk.

Aan de andere kant, als jij serverside wil valideren, dan zal je de data daar ook moeten aanspreken voor validatie. (tenminste dat begrijp ik uit je post), maar om dan de hele logica laag serverside te doen vind ik een vreemde keuze. Ik zou gewoon serverside checkpoints inbouwen, en de logica laag in de client houden.

[Gomez12]

drm schreef op dinsdag 24 september 2013 @ 00:09:
Dit is een typisch geval waar een domain specific language ("DSL") uitkomst kan bieden en m.i. op langere termijn ook de enige echt goede oplossing is. De taal zou kunnen compilen naar en/of geëvalueerd worden binnen verschillende talen.

Dit is imho sterk afhankelijk van het aantal wat er in gebruik gaat zijn.

Als het slechts om 1 berekening gaat dan betekent het introduceren van een DSL veelal dat niemand er echt meer uit komt, de JS-masters die snappen alles eromheen wel wat de GUI regelt, maar niet wat die berekening nou precies doet, de backend-masters snappen perfect wat er in de backend gebeurt maar niet wat er in de berekening gebeurt en de DSL-masters snappen enkel de berekening en niet wat er met het resultaat gebeurt.

Heb je nou 50 of 100 van die berekeningen dan zou ik idd zeggen DSL of als het echt je business logica is zelfs wellicht nodejs als backend. Maar met eentje???

[Razr]

RobertMe schreef op zondag 22 september 2013 @ 15:09:
Wat ik een keer heb gedaan is de logica opnemen in de server, logischerwijs, maar niet uitgewerkt als echte gecompilede code, maar als lambda expressions. Deze lambda expressions kun je at runtime weer compileren naar methodes die je gewoon kunt aanroepen (LambdaExpression.Compile / Expression<TDelegate>.Compile). Echter is een lambda expression een omschrijving van "iets". Deze kun je ontleden en omschrijven naar iets anders. In mijn (en jouw) geval kan dat dus KO zijn. Om deze ontleding te doen kun je gebruikmaken van de ExpressionVisitor. Je kunt dan dus (intern) een StringBuilder aanmaken en in elke Visit... method schrijf je het stukje benodigde KO code behorende tot die expression. In VisitBinary krijg je dan als voorbeeld dus iets als

C#:

this.Visit(node.Left);
switch(node.NodeType)
{
  case ExpressionType.Equal:
    _stringBuilder.Write(" = ");
    break;
}
this.Visit(node.Right);

Het voordeel van het gebruik van lambda expressions is ook dat deze compile time safe zijn. Wat de JS code natuurlijk nooit kan zijn omdat die logischerwijs niet gecompileerd is maar ook jouw (server side) business model niet kent.

Dat ziet er intressant, maar eigenlijk ook te ingewikkeld uit. Ik denk niet dat ik deze kant op wil om mijn probleem op te lossen, ik denk dat er voor mijn geval betere oplossingen zijn.

BasieP schreef op maandag 23 september 2013 @ 22:20:
Toch snap ik dat je logica op 1 plek wilt.
Ik snap deze zin niet helemaal

[...]

Dat lijkt me een reden om niet voor dat framework te kiezen. Zeker in de wereld waarin we nu leven lijkt het me handig om dingen als loosly coupled en modulair programming serieus te nemen.
Dat wil zeggen dat je als je straks een veldje toevoegd om te valideren, je alleen dat veldje (of setje veldjes) over de lijn stuurt, en niet je hele view. Je kan dan namelijk ook tegen verschillende servers valideren (mits restfull) en je kunt parallel valideren.
Verder minimaliseer je de dataoverdracht, en heb je als gebruiker een responsive webpage

Het gaat hier niet om valideren maar vooral om business rules. Met validatie kun je inderdaad een enkel veld heen en weer sturen, in dit geval niet. Als een waarde in een veld veranderd (veld A veranderd) moet je ook veld B en C hebben om D te kunnen berekenen. Dus alle velden (A,B,C en D) gaan naar de server en weer terug.

Biersteker schreef op dinsdag 24 september 2013 @ 00:14:
[...]

Hoeveel users gaat het om. Er ligt zeker waarde in om een gedeelte logica binnen een client te houden, zodat je de server ontlast voor simpel dom werk.

Aan de andere kant, als jij serverside wil valideren, dan zal je de data daar ook moeten aanspreken voor validatie. (tenminste dat begrijp ik uit je post), maar om dan de hele logica laag serverside te doen vind ik een vreemde keuze. Ik zou gewoon serverside checkpoints inbouwen, en de logica laag in de client houden.

Nogmaals het gaat hier hoofdzakelijk niet om validatie maar om business logica/rules. We willen in een soort van CRON job bepaalde entiteiten/modellen kunnen herrekenen als er een variable veranderd. Het herrekenen moet dus volledig aan de serverkant mogelijk zijn.

Het knelpunt is dat we een hele responsive applicatie hebben waarbij we bij een 'keyup' event het model herrekenen. Deze herreken actie wordt gedaan in JS omdat dit gewoon het meest snel is (geen roundtrip naar de server nodig met het hele (view)model). Maar deze logica moet ook (of alleen op) de server beschikbaar gaan worden.

Ik ga eens kijken naar DSL, misschien is het intressant maar het moet inderdaad geen overkill worden - ook omdat ik me er nog over moet inlezen. Allemaal super bedankt voor het meedenken in ieder geval, ik hoop dat ik mezelf een beetje duidelijk kan maken in mijn reacties

[Gomez12]

Biersteker schreef op dinsdag 24 september 2013 @ 00:14:
[...]
Aan de andere kant, als jij serverside wil valideren, dan zal je de data daar ook moeten aanspreken voor validatie. (tenminste dat begrijp ik uit je post), maar om dat de hele logica laag serverside te doen vind ik een vreemde keuze. Ik zou gewoon serverside checkpoints inbouwen, en de logica laag in de client houden.

Waarom vind jij serverside checken een vreemde keuze? Als ik heel eerlijk ben is dat de enige check die ik relevant vind. Client-side kan er best gechecked worden maar dat is enkel voor de leukigheid, niet voor het echie.

Maar eigenlijk ben ik onderhand wel benieuwd wat voor berekening de TS wil uitvoeren want als het puur rekenkundige regels volgt dan zou het 99% oid gelijk moeten zijn.
Op die basis heb ik in het verleden wel eens 1 functie-body op laten halen in verschillende systemen, de functieheader verschilde per taal (en het initialiseren van de variabelen etc) maar de variabelen waren gelijk en de uitkomst ging naar dezelfde variable. Dus het unieke deel van de functie (de berekening zelf, niet alle opsmuk eromheen) dat was simpelweg gelijk en kon gewoon lazy opgehaald worden

Het betrof hier wel een systeem met een stuk of 1000 van dit soort berekeningen dus wat ons betreft was het scheiden van rekenkunde en code wel verantwoord omdat het overal gebeurde, het was niet 1 uitzondering op een hele code-base het was gewoon de manier om rekenkundige dingen te schrijven en bijkomend voordeel was ook weer dat toen er een grafiekengenerator server kwam die ook gelijk kon beschikken over de 1000 berekeningen enkel de opsmuk was nog nodig.
Alleen hier zit je al extreem dicht tegen een DSL aan (wij kwamen er net niet aan door enkele berekeningen simpelweg uit te schrijven ipv functies als mod sqrt etc te gebruiken)

[Razr]

Gomez12 schreef op dinsdag 24 september 2013 @ 00:29:
[...]

Waarom vind jij serverside checken een vreemde keuze? Als ik heel eerlijk ben is dat de enige check die ik relevant vind. Client-side kan er best gechecked worden maar dat is enkel voor de leukigheid, niet voor het echie.

Maar eigenlijk ben ik onderhand wel benieuwd wat voor berekening de TS wil uitvoeren want als het puur rekenkundige regels volgt dan zou het 99% oid gelijk moeten zijn.
Op die basis heb ik in het verleden wel eens 1 functie-body op laten halen in verschillende systemen, de functieheader verschilde per taal (en het initialiseren van de variabelen etc) maar de variabelen waren gelijk en de uitkomst ging naar dezelfde variable. Dus het unieke deel van de functie (de berekening zelf, niet alle opsmuk eromheen) dat was simpelweg gelijk en kon gewoon lazy opgehaald worden

Het betrof hier wel een systeem met een stuk of 1000 van dit soort berekeningen dus wat ons betreft was het scheiden van rekenkunde en code wel verantwoord omdat het overal gebeurde, het was niet 1 uitzondering op een hele code-base het was gewoon de manier om rekenkundige dingen te schrijven en bijkomend voordeel was ook weer dat toen er een grafiekengenerator server kwam die ook gelijk kon beschikken over de 1000 berekeningen enkel de opsmuk was nog nodig.
Alleen hier zit je al extreem dicht tegen een DSL aan (wij kwamen er net niet aan door enkele berekeningen simpelweg uit te schrijven ipv functies als mod sqrt etc te gebruiken)

Het zijn niet eens alleen maar rekenzaken, ook bijvoorbeeld een module die op basis van een geselecteerde eenheid een controle en conversie/berekening uitvoert. Die logica houdt dus in dat er een controle is dat als de 'parent' liter is, een child alleen 'cl' of 'dl' mag zijn bijvoorbeeld. Zulke logica zou dan ook allemaal gedupliceerd moeten worden.

Omdat er 's nachts koppelingen zijn met andere systemen worden er waarden bijgewerkt, nadat de aanpassingen klaar zijn willen wij zelf een 'herreken' actie uitvoeren. Maar dat staat hier verder los van.

De reden van dit topic is dat ik benieuwd ben of hier goede oplossingen voor zijn (DSL lijkt er zeker een van zover ik kan zien trouwens). Een eenvoudigere oplossing zou zijn dat je na een wijziging alle data telkens naar je business layer haalt (we gebruiken KnockoutJS icm WebAPI) en daar dus alles herrekent en dan retourneert. Dit gaat prima werken, maar je verliest responsiveness ben ik bang.

[R4gnax]

Razr schreef op dinsdag 24 september 2013 @ 00:37:
[...]

De reden van dit topic is dat ik benieuwd ben of hier goede oplossingen voor zijn (DSL lijkt er zeker een van zover ik kan zien trouwens). Een eenvoudigere oplossing zou zijn dat je na een wijziging alle data telkens naar je business layer haalt (we gebruiken KnockoutJS icm WebAPI) en daar dus alles herrekent en dan retourneert. Dit gaat prima werken, maar je verliest responsiveness ben ik bang.

In dat geval doe je het parallel op; je rekent je set (snel) clientside door, maar wanneer de user invoer gedurende een 'langere' tijd stopt, zeg zo'n 2 seconden, vuur je ook een request met de huidige state van je model af naar de server om daar 'voor het echie' door te laten rekenen. Dat resultaat herintegreer je dan later weer met je client set.

Is de truc alleen nog om op de juiste manier een tijdelijke blokkade van extra clientside wijzigingen te blokkeren terwijl de sync met de server loopt. Mogelijk kun je nog één of twee wijzigingen gequeued houden en meteen verwerken zodra de server sync af loopt, maar veel verder dan dat zul je wss. niet kunnen gaan zonder de integriteit van je model aan te tasten.

[Gomez12]

Razr schreef op dinsdag 24 september 2013 @ 00:37:
[...]
Een eenvoudigere oplossing zou zijn dat je na een wijziging alle data telkens naar je business layer haalt (we gebruiken KnockoutJS icm WebAPI) en daar dus alles herrekent en dan retourneert. Dit gaat prima werken, maar je verliest responsiveness ben ik bang.

Tja, als het responsiveness vs business logica robuustness is dat weet ik wel waarvoor ik ga... (maar jullie lijken ergens anders voor te kiezen)

Wat je ook zou kunnen doen is om een 2e server neer te zetten die dit soort zaken afhandelt. Laat die server op node-js draaien en knal er wat get-webservices op zodat je c# daar de resultaten op kan halen. Dan kan je op nodejs en client-side dezelfde code draaien, in principe zou je de client zelfs kunnen verversen adhv node-js code (zou ik niet doen ik zou die node-js 100% intern houden maar ok).

Dan heb je niet direct een DSL nodig (ik begrijp dat het maar om 2 talen gaat die alletwee server-side kunnen draaien) en hoef je geen nieuwe codering aan te leren, alles kan in js of in c# (met web-service requests naar je nodejs)

[drm]

Gomez12:
Dit is imho sterk afhankelijk van het aantal wat er in gebruik gaat zijn.

Als het slechts om 1 berekening gaat dan betekent het introduceren van een DSL veelal dat niemand er echt meer uit komt, de JS-masters die snappen alles eromheen wel wat de GUI regelt, maar niet wat die berekening nou precies doet, de backend-masters snappen perfect wat er in de backend gebeurt maar niet wat er in de berekening gebeurt en de DSL-masters snappen enkel de berekening en niet wat er met het resultaat gebeurt.

Je bedoelt dat het problematisch is dat iedereen met zijn eigen vakgebied bezig is? Of bedoel je dat het vervelend is dat mensen met elkaar samen moeten werken? Ik snap het punt geloof ik niet zo.

Heb je nou 50 of 100 van die berekeningen dan zou ik idd zeggen DSL of als het echt je business logica is zelfs wellicht nodejs als backend. Maar met eentje???

Als je eenvoudige business logic heb, heb je ook een heel eenvoudige DSL.

Ik heb het al eens gedaan en on the long run heb je er vele malen meer profijt van.

[Gomez12]

drm schreef op dinsdag 24 september 2013 @ 18:23:
[...]
Je bedoelt dat het problematisch is dat iedereen met zijn eigen vakgebied bezig is? Of bedoel je dat het vervelend is dat mensen met elkaar samen moeten werken? Ik snap het punt geloof ik niet zo.

Mits je de organisatie hebt dat iedereen zijn eigen vakgebied heeft en dat ze alle vakgebieden afdekken dan is het niet erg.

Alleen dan gooi je ook niet snel dit soort vragen op een forum, dan heb je het eerst intern erover en dan blijkt dat je gewoon alle expertise in huis hebt.
Ik ga meer uit van een bedrijf wat niet alle expertise in huis heeft en wat dus expertise erbij moet leren, erbij leren is nooit verkeerd, maar erbij leren voor 1 project met een kleine impact leidt veelal tot wel iets ervan weten maar net niet de laatste / juiste technieken.
Heb je de mogelijkheid om de expertise erbij te leren en ga je dit ook voor andere projecten gebruiken dan is het niet verkeerd, maar 1 project enkel 1 expertise erbij leren, tja...

[drm]

Gomez12:
Mits je de organisatie hebt dat iedereen zijn eigen vakgebied heeft en dat ze alle vakgebieden afdekken dan is het niet erg.

Alleen dan gooi je ook niet snel dit soort vragen op een forum, dan heb je het eerst intern erover en dan blijkt dat je gewoon alle expertise in huis hebt.

Fair enough, maar dat kan ik niet beoordelen en moet TS zelf doen.