Mon Conclussions (voir section ci-dessous pour le pourquoi):
L'utilisation des rôles d'application SQL ne joue pas bien avec Le regroupement de connexions ne doit pas non plus être utilisé directement dans les applications utilisateur finales (uniquement sur un niveau professionnel).
L'alternative SQL enlèverait beaucoup d'avantages de l'utilisation de linq, car elle dépend des SP.
Ma recommandation:
Si vous avez un niveau d'affaires/serveur, faire l'autorisation au niveau de l'application au lieu de compter sur l'autorisation sql. Si vous souhaitez toujours autoriser, disposez d'un compte associé à l'application de niveau métier et associez-lui un rôle normal.
S'il s'agit d'une application cliente qui se connecte directement à sql. L'utilisateur aura toujours la permission d'appeler ce à quoi son identité a accès, et le mot de passe de l'application est là. Si vous n'êtes pas à l'aise avec ce niveau d'accès, vous avez besoin d'un niveau professionnel.
Si vous souhaitez toujours procéder à l'approche, désactivez la mise en commun des connexions. Pour réduire les frais généraux d'ouverture/fermeture, ouvrez les connexions explicitement.
explication/références complètes:
Un problème est qu'il ne joue pas bien avec la mise en commun de connexion. C'est indépendamment de linq2sql. Voir à la fin de this dans msdn.
Il existe 2 alternatives depuis le serveur sql 2005 (msdn link), on est également mentionné dans le thread auquel vous avez lié, mais il signale également qu'il peut mal se passer. Notez que c'est une option non sécurisée dans un scénario à 2 niveaux, comme lorsque l'application utilisée par les clients se connecte directement à SQL. Dans ces cas le pwd pour n'importe quelle application dans l'ordinateur du client serait exposé dans ceux-ci. C'est plus sûr si c'est un niveau d'entreprise qui se connecte, mais c'est précisément le cas où vous voulez vraiment la mise en commun des connexions.
L'autre alternative mentionnée dans mon deuxième lien vers msdn, fonctionne bien avec le regroupement de connexions. Il est basé sur les procédures stockées et l'instruction execute as. L'exécution est appelée dans la procédure, et après l'exécution de la procédure, le contexte est inversé. C'est génial, mais ça donnerait beaucoup de ce que vous obtenez avec linq2sql en utilisant la route sp.