在SQL Server中，您可以拥有应用程序角色安全性，通过该安全性，您可以提供源自特定应用程序的特定权限。
您可以执行sp_SetAppRole（）来设置应用程序角色，但是想知道在使用摩擦力最小的LINQ2SQL datacontext时如何实现这一点。
我看过这个链接： http://social.msdn.microsoft.com/Forums/en-US/linqprojectgeneral/thread/e25e98a6-b0ac-42fc-b70c-2b269a7fa1cb但希望采用更清洁的方法/
答案 0 :(得分：1)
我的结论（见下节部分原因）：
使用SQL应用程序角色不能很好地处理连接池，也不应该直接在最终用户应用程序中使用（仅限于业务层）。
SQL替代方案将使用linq带来很多好处，因为它依赖于SP。
我的建议：
如果您有业务层/服务器，请在应用程序级别执行授权，而不是依赖于sql授权。如果您仍想要授权，请拥有与业务层应用程序关联的帐户，并将正常角色与其关联。
如果是直接连接到sql的客户端应用程序。用户仍然有权调用他（她）的身份可以访问的任何内容，并且应用程序密码就在那里。如果您对具有该级别访问权限的用户不满意，则需要业务层。
如果您仍想继续此方法，请关闭连接池。要减少打开/关闭开销，请明确打开连接。
完整的解释/参考：
一个问题是连接池不能很好地发挥作用。这与linq2sql无关。请参阅msdn。{/ p>中this的末尾
自sql server 2005 (msdn link)以来有两种选择，在您链接的主题中也提到了一个，但它也指出它可能出错。
请注意，它是2层方案中的不安全选项，例如客户端使用的应用程序直接连接到sql时。在这些情况下，客户端计算机中任何应用程序的密码都将暴露在那些应用程序中。如果它是连接的业务层，则更安全，但这正是您真正需要连接池的情况。
我在msdn的第二个链接中提到的另一个选项，适用于连接池。它基于存储过程和execute as语句。在过程内部调用execute，并在执行过程后恢复上下文。这很棒但是真的会通过sp路线从linq2sql中获得很多东西。