Impact FrameWork pour le client d'un Service WCF
Bonjour,
Dans le cadre de mon travail, je suis en train de développer un Service WCF qui sera consommé par un ou plusieurs clients.
Ce Service WCF sera exposé en basicHTTPBinding et WebHTTPBinding.
Avant tout, je signale que je travaille avec Visual Studio 2010 Beta 2 et que j'ai mis le projet en FrameWork 3.5 au départ.
Pour ma DAL, j'étais parti sur Entity FrameWork et j'ai créé le model (qui pointe sur deux tables et sur des procédures stockées). En effet, on a fait le choix d'utiliser presque exclusivement des procédures stockées (qui peuvent renvoyer des données simples (int, ...) mais aussi des des types plus complexes (nom, prenom, ... par exemple).
En ajoutant des Fonctions sous Entity Framework (pour utiliser mes procédures stockées), j'ai vu qu'une nouvelle option était apparue : les types complexes. D'aprés ce que j'ai compris, ça permet de voir ce que la procédure stockee retourne, et de créer un type sur mesure. C'est idéal pour ce que je voudrais faire car mes Procédures Stockées ne renvoi pas de "véritables Entités". Je ne souhaite pas les mapper avec une entité.
Par contre, j'ai rémarqué que pour utiliser cette fonction, il fallait passer le projet en Framework 4.0. En changeant le FrameWork de ma DAL, je suis obligé de changer le Framework de mes autres Bibliothèques de classe (qui utilisent la dll de la DAL).
J'ai donc plusieurs questions :
- Est-ce viable d'utiliser des maintenant le FrameWork 4.0 ?
- L'utilisation du FrameWork 4.0 aura t'il un quelconque impact sur le client qui voudra intérroger mon Service WCF ? Si par exemple il travaille en .NET 3.5 ? Ca change quelque chose pour lui ?
J'ai vu qu'il y avait plusieurs méthodes pour exposer son service, avec WSDL mais aussi en donnant les .dll avec les classes. Dans ce second cas, ça va poser problème ?
- Y'a t'il une autre solution que les Types Complexes pour utiliser de manière simple des procédures stockées qui renvoie des données avec EF sans avoir à les mapper avec une Entité ?
Merci d'avance pour votre aide.
Ps : Une des solutions est bien sur de laisser tomber Entity Framework. Selon vos réponses, j'opterais probablement pour cette solution. Merci.
