Sql server 关于使用LINQ和存储过程访问数据的问题（不要问哪个更好！）

首先，我不想再引发另一场关于LINQ和存储过程的辩论

对于这个问题，假设我将使用SQL server存储过程，并将通过LINQ访问这些存储过程。我再次使用存储过程，不管是对是错，因为我希望在存储过程级别强制执行安全性，而不是在基础表和视图上强制执行安全性。我再次使用LINQ，无论是对是错，因为我想学习它

综上所述，我的LINQ查询应该是相对简单的SELECT语句，显然只是指读取问题中的数据，而不是包含分组或计算或其他更复杂内容的LINQ查询。这个假设是基于我将这个逻辑放入T-SQL的计划。换言之，我的LINQ查询将相对愚蠢。此外，考虑到我希望在存储过程级别强制执行安全性，并且不允许访问基表，我认为这种方法与该目标是一致的

我的逻辑在1中有什么缺陷吗

如果我直接对基表使用LINQ，我显然必须直接在这些基表上强制实施安全性。这似乎很明显，但我想确认一下

我的逻辑在2中有什么流动吗

---

LINQ本身是非常通用的，因为有LINQ到对象、LINQ到xml、LINQ到sql、LINQ到EF等等。我想您可能会追求LINQ到sql功能，而不是LINQ到EF。通过这样做，您的所有集合都是由存储过程提供的，并在应用程序中使用Linq查询这些集合，我想说的是，您将教会自己如何利用Linq的强大功能，尤其是Linq到Sql。在理解LINQtoSQL如何生成发送到服务器的Sql查询时，您将错过很多专门知识，因为您将只能执行您所说的非常基本的“哑”查询。你甚至不能在LINQtoSQL中进行连接。您将错失正确理解Linq to Sql的ORM功能、进入DataContext的缓存以及允许您从集合中插入/更新/删除项的ActiveRecord行为的机会

虽然我并不反对这样做，但这是一种将存储过程和linq结合起来的非常有效的方法，我认为这是学习linq的一种不好的方法。试着用一种直截了当的方法让你的脚湿透，这种在VisualStudio中使用.dbml文件的数据建模方法是Linq福音派在2008年提倡的。虽然我认为这种方法在部署大型、可行的项目时是有缺陷的，但是自学Linq和LINQtoSQL是非常好的。一旦您了解了事情是如何工作的，您将能够了解如何通过存储过程正确地利用这一点来分离访问控制—这是一种一直受到SQL Server传播者称赞的方法—以及如何处理.dbml建模方法未解决的问题—具体而言，就是数据库架构升级问题

有人可能会说，您也许还应该留意实体框架提供了什么，但如果您正处于学习阶段，我衷心建议您改为使用Linq to Sql。它不那么复杂，工作正常，在VS工具集中得到很好的支持，而且您不必学习实体SQL