2

我正在开发一个 .net 3.5 中的新项目。

目前客户端正在使用存储过程，我们真的很想使用 LINQ to SQL 来代替。他们使用存储过程的主要原因是因为他们认为它们更容易更新等，他们不使用任何特殊权限或这样我可以看到证明在 LINQ to SQL 上使用存储过程是合理的，只是他们不想更改。

我想如果我可以向他们提供一个解决方案，他们可以轻松地将更改部署到 LINQ to SQL，他们可能更愿意改变主意。

因此，我对 asp.net 项目（而不是 mvc）很好奇如何更新在构建过程中创建的各种程序集。

例如，我所有的 LINQ 代码都在 System.DataAccess 项目中，并且部署到生产环境中，然后使用 LINQ 识别出产品错误。仅部署更改后的 DataAccess 项目（或者更确切地说，部署自 prod 部署以来发生重大变化的任何项目）有多困难。

我不确定会帮助这种情况的一件事是，每次有构建时，所有项目的构建号都会更新，无论是否实际发生更改，因此只需查看项目的版本号即可不足以确定需要重新部署的项目。

我什至不确定是否可以修改构建，所以只有更改后的项目才会更新其版本？

所以基本上我只是对那里的各种修补过程以及利弊（即需要 iis 重置等）感到好奇。

干杯

4

2 回答 2

0

SQL 存储过程和 LINQ-SQL 不是相互排斥的。

通常，对于复杂、贪婪和资源密集型操作，您仍然使用 SQL 存储过程（例如，依赖于复杂子查询/数据库逻辑的 INSERT 操作）并将它们拖到 LINQ-SQL 画布上。

在修补方面 - 您当然可以直接在 SQL Server 中修补这些存储过程，并且不需要重新编译 LINQ-SQL 类 - 只要签名不改变（参数/返回类型）。

在从某些程序集更新版本号方面 - 不理想。变得非常混乱，甚至可能导致问题（强命名）。

您应该将所有数据库逻辑/LINQ/CRUD 操作放在一个程序集 (DAL) 中。

如果您真的想隔离 LINQ 逻辑并启用这些程序集的独立部署 - 也许您应该考虑将您的解决方案划分为 Web/应用程序服务器？即有您的 LINQ DAL 程序集和类似外观的程序集，它们在应用程序服务器上公开这些操作，然后您的网站在单独的 Web 服务器上。

根据您的体系结构，您可以使用 ASMX/WCF/.NET Remoting 来促进 Web/应用服务器之间的调用。（WCF 不能跨域工作）。

话虽如此，如果您正确地完成了 LINQ-SQL 类（简单的 LINQ CRUD 操作、视图、存储过程的良好组合），如上所述，您仍然可以轻松地修补存储过程而不会影响您的应用程序。

于 2010-06-25T01:13:44.783 回答
0

两者都有优点和缺点。

SQL 存储过程快速高效。您可以使用存储过程执行繁重的 SQL 操作，这将比您在代码中执行的任何操作都快得多，但它是另一层。

发生更改时，LINQ 不需要太多的维护工作。很容易编写代码。

对于任何方法，您根本不需要重置 IIS。为每个版本更新程序集文件版本是一个很好的做法 - 仅当您更改该程序集中的代码时。升级版本只是因为会很乱而且不需要。

两者都可以轻松修补。我发现 LINQ 更容易恕我直言。如果表结构发生变化，我不需要修改存储过程和使用这些存储过程的函数。这是一个快速更改脚本，您的 DBML 应该已经更新，因为您一直在使用新版本进行测试，然后它是一个部署。

我总是将我的 LINQ 和部分数据类放在同一个程序集中，因此它是一个简单的 DDL 版本。

于 2010-06-24T15:30:01.657 回答