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