Bon .NET, c'est juste un nom pour dire "web services microsoft".
Le principe des web services ce sont des biblio objets sur le réseau que tu appelles par un annuaire.
En gros tu n'as plus besoin de savoir si ta ressource est locale à ton pc, sur ton réseau d'entreprise ou sur internet, ce n'est pas du travail à distance, c'est juste une couche logicielle pour accéder à des API quelque soit leur emplacement sur le net, et d'avoir des traitements supplémentaires dessus comme faire payer leur accés (c'est l'argument qui est le plus avancé).
Imaginons que tu ais besoin d'un convertisseur euros/francs 2 fois par an, mais que ça te couterais plus cher de le développer que de payer l'appel à un web services 2 fois par an, tu intégre dans ton programme l'appel de fonction au web services du style
et hop ça marche et tu n'a pas à maintenir le code qui convertis les euros en francs. Bon cet exemple est débile, mais pour des traitements lourd, c'est plus rentable. D'autant plus que rien n'empeche d'avoir des services libres.
Quand tu développe une application, tu la pense sous forme de briques maintenues par d'autres, c'est le principe de ne pas réinventer la roue.
Une routine qui sert 1% du temps sur un programme servira 100% du temps pour 10000 programmes.
A terme cela peut alléger les applications (enfin sur les schémas fonctionnels, pas en mémoire ni en cpu :-), car les fonctions rarement utilisées seront faites ailleurs.
Bon je suis conscient que mon explication n'est pas forcement claire.
C'est une évolution pas une révolution de l'idée de "comment faire un programme" au même titre que les librairies partagées au lieu des librairies statiques, et du concept des librairies partagées distantes.
Dernier point, on peut faire des web services en n'importe quel langage, pour l'instant c'est bcp plus simple de les faire en java ou en c# car il y a déjà les API et les librairies pouvant les gérer et il vaut mieux les créer à partir d'un langage objet.
[^] # Philosophie de .NET
Posté par darkleon . En réponse à la dépêche Mono change de licence. Évalué à 10.
Le principe des web services ce sont des biblio objets sur le réseau que tu appelles par un annuaire.
En gros tu n'as plus besoin de savoir si ta ressource est locale à ton pc, sur ton réseau d'entreprise ou sur internet, ce n'est pas du travail à distance, c'est juste une couche logicielle pour accéder à des API quelque soit leur emplacement sur le net, et d'avoir des traitements supplémentaires dessus comme faire payer leur accés (c'est l'argument qui est le plus avancé).
Imaginons que tu ais besoin d'un convertisseur euros/francs 2 fois par an, mais que ça te couterais plus cher de le développer que de payer l'appel à un web services 2 fois par an, tu intégre dans ton programme l'appel de fonction au web services du style
francs = webservices_du_fournisseur_x.euros2francs(euros, iddemaboite);
et hop ça marche et tu n'a pas à maintenir le code qui convertis les euros en francs. Bon cet exemple est débile, mais pour des traitements lourd, c'est plus rentable. D'autant plus que rien n'empeche d'avoir des services libres.
Quand tu développe une application, tu la pense sous forme de briques maintenues par d'autres, c'est le principe de ne pas réinventer la roue.
Une routine qui sert 1% du temps sur un programme servira 100% du temps pour 10000 programmes.
A terme cela peut alléger les applications (enfin sur les schémas fonctionnels, pas en mémoire ni en cpu :-), car les fonctions rarement utilisées seront faites ailleurs.
Bon je suis conscient que mon explication n'est pas forcement claire.
C'est une évolution pas une révolution de l'idée de "comment faire un programme" au même titre que les librairies partagées au lieu des librairies statiques, et du concept des librairies partagées distantes.
Dernier point, on peut faire des web services en n'importe quel langage, pour l'instant c'est bcp plus simple de les faire en java ou en c# car il y a déjà les API et les librairies pouvant les gérer et il vaut mieux les créer à partir d'un langage objet.