Discussion :

[neuropathie]

Bonjour,
Je dois mettre en place une architecture de projet en technologies Microsoft. Le projet consiste en la mise en place d'une API. Cette API doit par le biais de Webservices prendre des données sous format XML d'un middleware, traiter ces données pour remplir une base de données.
D'un autre côté des application Web et mobiles peuvent à n'importe quel moment par le biais de webservices contacter l'API pour interroger la base de données.
Ma proposition est basée sur du ASP.NET, C#, Linq, entity Framework.

Est ce que quelqu'un aurait une idée ou une aide à ce sujet, sur les technologies mais plus en terme d'architecture de l'API.

Merci d'avance.

[chamamo]

D'après ce que tu viens de décrire, je pencherai pour ASP.NET Web Api.

[DotNetMatt]

Ca dépend, ASP.NET Web API est très bien pour des projets légers, type appels en AJAX (REST/JSON), et surtout pour des besoins très classiques.

Cependant si on a besoin de gérer des scénarios particuliers (type one way messaging, queues de messages, duplex, etc.), ou encore si on veut utiliser des canaux de communication rapides (TCP/UDP/Named Pipes...), il faut se tourner vers WCF.

Donc ça dépend pas mal de ton projet, si les communications passent pas internet ou si tout se fait en local, etc...

[jouana]

Je te conseil WPF service application + ado.net

Facile à utiliser dans tes projet après via les web references

[chamamo]

Ca dépend, ASP.NET Web API est très bien pour des projets légers, type appels en AJAX (REST/JSON), et surtout pour des besoins très classiques.

Légers? tu peux détailler s'il te plait? car j'ai mis en place un back office en Web Api qui peut être consommé depuis plusieurs type d'appareil (pc, pda, mobile) qui est assez conséquent et jusqu'à présent je n'ai eu aucun souci, ce que j'aime le plus c'est la facilité de le mettre en place, moins de config...etc.

Cependant si on a besoin de gérer des scénarios particuliers (type one way messaging, queues de messages, duplex, etc.), ou encore si on veut utiliser des canaux de communication rapides (TCP/UDP/Named Pipes...), il faut se tourner vers WCF.

Entièrement d'accord.

Donc ça dépend pas mal de ton projet, si les communications passent pas internet ou si tout se fait en local, etc...

Je ne sais pas si ça change quelque chose, que ce soit WCF ou Web Api les deux peuvent être déployé sur internet ou en réseau local

[neuropathie]

Merci pour vos réponses,
Mon client actuellement est une banque (donc coté sécurité ca doit etre poussé)
Le client met à ma disposition des fichiers XML et ca s'arrete là. De mon coté mon API doit etre capable de prendre ces fichiers XML, les traiter et remplir la base de données.
D'un autre coté des appli mobiles et portails web peuvent utliser mon API pour accéder à la base de données.
Il peut exister des cas de mise à jour, c'est à dire qu'un utilisateur peut mettre à jour certaines données et l'API met à jour la base
Donc pour moi le plus important par ordre de priorité:
-l'API et son architecture.
-la sécurité de l'API
-L'API vers la base de données.

[DotNetMatt]

Légers? tu peux détailler s'il te plait? car j'ai mis en place un back office en Web Api qui peut être consommé depuis plusieurs type d'appareil (pc, pda, mobile) qui est assez conséquent et jusqu'à présent je n'ai eu aucun souci, ce que j'aime le plus c'est la facilité de le mettre en place, moins de config...etc.

Par "léger" il fallait comprendre ce que j'ai écrit un peu plus loin, à savoir des besoins classiques, et surtout purement HTTP. C'est d'ailleurs pour cela que Web API est préfixé par ASP.NET.

Je ne sais pas si ça change quelque chose, que ce soit WCF ou Web Api les deux peuvent être déployé sur internet ou en réseau local

Oui mais pour les scénarios spécifiques que j'ai décrit (TCP/UDP...), il vaut mieux être en local. On peut certes faire du TCP over Internet mais bon ce n'est semble-t-il pas la meilleure chose à faire.

[EDIT] En complément, voici les principales différences entre WCF et ASP.NET Web API : WCF and ASP.NET Web API

[jouana]

tu n'as pas vraiment le choix et TCP c'est mieux que de l'UDP à travers le web

Même si c'est plus lourd