Quelqu'un peut-il me dire quel est le besoin/l'avantage d'utiliser un service web avec un gui asp.net et d'utiliser Linq to SQL? La couche de service Web semble inutile. Linq to SQL est complètement nouveau pour moi et je fais des recherches car je suis en train de mettre en place un nouveau projet. Est-ce que quelqu'un a de l'expérience avec ça?Pourquoi utiliser un service Web avec Linq to SQL?
Vous exposeriez des services pour les cas dans lesquels d'autres applications pourraient avoir besoin d'accéder à vos données (comme un client intelligent, une autre application, une application WinForms, etc.). Beaucoup de gens développeront en utilisant des services Web pour éviter de devoir se restructurer aux services Web à l'avenir.
Dans presque toutes les applications Web professionnelles/professionnelles, vous souhaitez séparer le niveau de l'interface utilisateur de la couche d'accès aux données afin de ne pas intégrer Linq aux appels SQL dans le niveau de l'interface utilisateur. Au lieu de cela, vous disposez d'un niveau de service intermédiaire, que ce soit ses services Web, WCF ou simplement une DLL avec une logique métier qui orchestre votre couche d'accès aux données. Les niveaux indépendants sont plus faciles à maintenir, à mettre à jour, à refactoriser et à apprendre. L'investissement initial dans leur création en vaut la peine.
Ce n'est certainement pas nécessaire, mais cela peut être pratique si vous souhaitez conserver votre couche d'accès aux données sur un serveur distinct de votre serveur de présentation (ASP.NET). Un service Web vous permet de limiter la communication entre les deux serveurs au port 80 uniquement.
Notez que cela peut s'appliquer à tout ancien ADO.NET ou à tout autre élément.
Conforme à l'affiche précédente. Vous voudrez probablement le faire pour appliquer l'idée de «Séparation des préoccupations» ...
Les services Web sont devenus une couche de séparation, car ils étaient conçus comme un moyen agnostique d'envoyer des données à d'autres logiciels. Ce sont des sites Web qui servent des informations à d'autres logiciels et non directement à l'utilisateur.
Un webservice est une couche de séparation révisée pour un site Web et ne peut pas remplacer complètement une bonne séparation de données, de logique métier et d'interface utilisateur. Faites comme votre logique vous le dit, mais méfiez-vous des baisses de performances que vous payez si vous n'avez pas besoin de communiquer avec un autre logiciel.
Oui, il y a une surcharge pour l'utilisation d'un niveau intermédiaire de service Web, ne le faites pas simplement parce que ça sonne bien, faites-le seulement quand c'est absolument nécessaire, et même alors vous aurez toujours votre logique métier dans une sorte de bibliothèque. – cfeduke
Tout à fait d'accord avec Ovidiu Pacurar. Les services Web ne sont PAS un bon choix pour la modélisation des couches de préoccupation. Vous devriez le faire en utilisant le bon vieux design OO. Il n'y a aucune raison pour qu'une application Web appelle les services Web en elle-même pour l'accès aux données sauf s'ils sont destinés aux appels ajax client ou si vous devez exécuter la couche d'entreprise/données sur un autre serveur pour des problèmes de sécurité extrêmes.
Et si sa sécurité concerne WCF est un meilleur choix IMO (juste un PITA). – cfeduke
merci cfeduke! encore une fois, je suis nouveau alors ... nous avons un projet asp.net et un projet de service web dans notre solution - suggérez-vous de créer un troisième projet pour le linq OU de mettre le linq dans le service web? – user30788
Je suis assez sûr que cfeduke dit que les requêtes linq iraient en toute sécurité dans le service web. C'est en fait un modèle assez standard même pour les implémentations non-webservice. – MojoFilter
k merci! c'est ce que je pensais juste vouloir confirmer! – user30788