[.NET/Alg] BusinessLogic nog steeds op de server ?

[whoami]

Ik heb eens zitten nadenken...

Als je een windows - applicatie hebt (een enterprise application), dan zet je normaal gezien de business-logica op de server.
Op die manier kan je, indien de BL moet veranderen, deze wijzigingen makkelijk deployen.

Echter, ik vraag me af of dit nog nodig is. Met de huidige mogelijkheden (zoals het Updater Application block van MS), is het mogelijk dat de applicatie checked of het een nieuwe versie nodig heeft van bepaalde assemblies. Indien dit het geval is, dan kan de applicatie deze nieuwe versie gaan downloaden en nadien gebruiken.
Op die manier is het dus mogelijk om, indien de BR veranderen, de gewijzigde DLL's op een virtual directory te zetten op de webserver. De applicatie kan checken (bij opstarten, of op regelmatige tijdstippen), of er nieuwe versies moeten gedownloaded worden, en indien dit het geval is, kan deze dat doen.
Op die manier werk je ook steeds met de nieuwste BR, en is het ook makkelijk om je wijzigingen te deployen.

Hoe denken jullie hierover ? Zie ik iets over het hoofd ?

[BertS]

Het enige nadeel dat ik kan bedenken is 'netwerk-traffic'

Maar de functionaliteit van het Updater Block kon je toch al lang zelf bouwen? Mijn VB6 applicaties gaan ook altijd met een auto-updater de deur uit (controleren op nieuwe versie bij het starten van de applicatie en dan gewoon een installer (silent) uitvoeren)

[whoami]

bee-es schreef op vrijdag 25 maart 2005 @ 19:01:
Het enige nadeel dat ik kan bedenken is 'netwerk-traffic'

Als je BL op de server staat, dan heb je ook netwerk traffic.

Maar de functionaliteit van het Updater Block kon je toch al lang zelf bouwen?

Ja, natuurlijk, maar daar gaat het eigenlijk niet om.

[sopsop]

Zoals je het nu schetst staat de business-logic nog steeds op de server. Alleen download je dat nu eerst.

[whoami]

boppert schreef op vrijdag 25 maart 2005 @ 19:29:
Zoals je het nu schetst staat de business-logic nog steeds op de server. Alleen download je dat nu eerst.

Jah, tuurlijk staat het op de server, maar het wordt niet meer uitgevoerd op de server...

[beany]

ik kan niet helemaal zien waarom je de BL op de client zou draaien... het draait toch prima op de server?? Enige wat ik me kan bedenken is de load op de servers... Maar ja, het is of de load op de servers of het extra dataverkeer wat je gaat krijgen met de downloads(en die zal hoger zijn dan het dataverkeer dat je hebt wanneer de BL aan de server kant zit) en ik denk dat dataverkeer duurder is dan CPU, toch??

[BertS]

whoami schreef op vrijdag 25 maart 2005 @ 19:23:
[...]

Als je BL op de server staat, dan heb je ook netwerk traffic.

Uiteraard, de afweging is dus: wat levert minder traffic op.
zie ook de opmerking van beany. Wat betreft kosten maakt het natuulijk nogal verschil of het over internet moet of dat het over een LAN gaat. In het laatste geval kan ik me voorstellen dat traffic goedkoper is dan cpu.

Ja, natuurlijk, maar daar gaat het eigenlijk niet om.

Waarom dan wel? Dan is er toch eigenlijk niets veranderd?
(hoewel het natuurlijk altijd zinvol is om eens te kijken of een in het verleden gemaakte keuze nog steeds wel de juiste is)

[Woy]

Het ligt er ook aan in wat voor omgeving het draait. Als de omgeving niet te vertrouwen is ( Dus bijvoorbeel idereen op internet kan er gebruik van maken ) dan kan je de BL beter op de server kant laten, anders moet je nog steeds alle input op de server weer gaan controleren en dan ben je alles dubbel aan het doen.

[EfBe]

er zijn meerdere soorten BL:
1) field oriented BL: (ID > 0)
2) entity/BO wide BL: (shipdate >= orderdate)
3) cross BO/entity BL: (customer.GoldCustomer == true if customer ordered more than N orders in the last M months)

3) is geschikt voor op de server, 1 en 2 hoeven dat niet te zijn en kunnen op de client worden afgehandeld.

Verder is het updater block wel aardig maarje moet wel je assemblies signen EN je moet er rekening mee houden dat je applicatie met veranderende versie nummers kan omgaan (dus dat er policy files worden meegeleverd)