我正在研究.net 3.5中的新项目。
目前客户端正在使用存储过程，我们真的想使用LINQ to SQL。他们使用存储过程的主要原因是因为他们认为它们更容易更新，因此，他们不使用任何特殊权限，或者我可以看到证明使用存储过程而不是LINQ to SQL，只是他们不想改变。
我想如果我能给他们一个解决方案，他们可以轻松地将更改部署到LINQ to SQL，他们可能会更愿意改变主意。
因此我对asp.net项目（不是mvc）感到好奇，如何更新在构建过程中创建的各种程序集。
例如，假设我的所有LINQ代码都在System.DataAccess项目中并且部署到生产中，然后使用LINQ识别prod bug。仅部署已更改的DataAccess项目（或者更确切地说是自prod部署以来发生重大更改的任何项目）是多么困难。
有一件事我不确定是否有助于这种情况是每次有一个构建时，构建号都会在所有项目上得到更新，无论是否实际发生了变化，只需查看版本号即可这些项目不足以确定需要重新部署的项目。
我甚至不确定是否可以修改构建，因此只有更改的项目更新了版本？
所以基本上我只是对各种修补过程以及利弊（即需要iis重置等）感到好奇。
干杯
答案 0 :(得分：0)
两者都有利弊。
SQL Stored Proc是快速有效的。您可以使用Stored proc执行繁重的SQL操作，这将比您在Code中执行的操作更快地执行，但它是另一层。
LINQ在发生更改时不需要那么多的维护工作。编码很容易。
您无需为任何方法重置IIS。只有在更改该程序集中的代码时，才能更新每个版本的程序集文件版本。升级版本只是因为杂乱而且不需要。
两者都很容易修补。我发现LINQ更容易恕我直言。如果表结构发生变化，我不需要修改存储过程和使用这些存储过程的函数。这是一个快速更改脚本，您的DBML应该已经更新，因为您已经使用新版本进行测试，然后是部署。
我总是在同一个程序集中有我的LINQ和部分数据类，所以这是一个简单的DDL版本。
答案 1 :(得分：0)
SQL存储过程和LINQ-SQL不是互斥的。
通常，对于复杂，贪婪和资源密集型操作，您仍然使用SQL存储过程（例如，依赖于复杂子查询/ db逻辑的INSERT操作）并将它们拖到LINQ-SQL画布上。
在修补方面 - 您当然可以直接在SQL Server中修补这些存储过程，并且不需要重新编译LINQ-SQL类 - 只要签名不会更改（参数/返回类型）。
在更新某些装配的版本号方面 - 并不理想。变得非常凌乱，甚至可能导致问题（强命名）。
您应该将所有数据库逻辑/ LINQ / CRUD操作放在一个程序集（DAL）中。
如果您真的想要隔离LINQ逻辑并启用这些程序集的独立部署 - 也许您应该考虑将解决方案划分为Web / app服务器？我有你的LINQ DAL程序集和类似Facade的程序集，它在应用程序服务器上公开这些操作，然后在单独的Web服务器上公开你的网站。
根据您的体系结构，您可以使用ASMX / WCF / .NET Remoting来促进Web / app服务器之间的呼叫。 （WCF不跨域工作）。
话虽如此，如果您正确完成了LINQ-SQL类（简单的LINQ CRUD操作，视图，存储过程的良好组合），如上所述，您仍然可以轻松修补存储过程而不会影响您的应用程序。 / p>