在哪里放置SQL逻辑

如果需要大量的数据操作,请将其保存在存储过程中的数据库中。如果查询可能会发生一些变化,那么数据库中的更好位置也会更好,否则可能需要为每个变化重新部署。

将工作的主要部分保存在存储过程中具有灵活性的优势-我发现修改过程比实现程序更改更容易。不幸的是,灵活性是一把双刃剑;做出不明智的改变也容易得多。

我建议看一下LinqToEntities,它提供了一个围绕任何SQL语句(CRUD)的对象关系映射包装器,抽象出写入数据库所需的逻辑,并允许您编写OO代码,而不是使用sqlConnections和sqlCommands。

OO代码(save方法不存在,但您可以获得其要点):

// this adds a new car to the Car table in SQL, without using ANY SQL code
Car car = new Car();
Car.BrandName = "Audi";

Car.Save(); //save is called something else and is on the 
// datacontext the car is in, but for brevity sake..

SQL命令中的字符串形式的SQL代码:

// open sql connection in your app and 
// create Command that inserts car
SqlConnection conn = new SqlConnection(connstring);
SQlCommand comm = new SqlCommand("INSERT INTO CAR...");

// execute

对存储过程进行版本控制和维护是一场噩梦。如果您没有遇到严重的性能问题(您认为将使用存储过程解决),我认为最好在C代码中实现逻辑(Linq、SubSonic或类似的东西)。

关于在.NET源代码中或在SQL Server存储过程中嵌入代码之间的性能差异,实际上应该看不到这两种方法之间的区别!

这是因为如果两个不同源中的数据访问T-SQL相同,SQL Server将生成相同的执行计划。

您可以通过运行SQL Server事件探查器跟踪并比较由两个不同的T-SQL查询源生成的执行计划来看到这一点。

有鉴于此,回到您的问题的要点,您对实现的选择应该由易于开发和您未来的可扩展性需求决定。由于您似乎是该项目的唯一负责人,所以请按照您的喜好进行操作,我怀疑这是为了将代码集中在Visual Studio数据访问层(DAL)内。

但是,当您在组织/团队中具有单独的开发功能时,存储过程可以自行生成。例如,您的团队中可能有数据库开发人员,他们可以为您创建数据访问代码,并且可以独立于应用程序创建数据访问代码,从而使您可以自由地处理其他代码模块。

更新部署:如果需要更新过程,可以在不让用户知道的情况下更新存储过程,而不使服务器脱机。更新c意味着向所有用户推出一个新的exe!

看一看 Entity Spaces . 这是一个代码生成工具——但它可以做得更多。

学习这个工具需要做少量的腿部工作,但是一旦你启动并运行起来,你将永远不会回头。节省工时。(顺便说一句,我不为他们工作!)

我应该将SQL逻辑放入存储过程吗

这取决于SQL逻辑是什么,不是吗?如果它纯粹与数据库相关,那么存储过程可能是最合适的。如果它是__业务逻辑_,决定应用程序如何运行的规则,那么它肯定属于您的应用程序。

哪一个最容易维护?

我个人认为应用程序端代码更容易,因为现代语言(如C)比SQL更具有表达能力。在T-SQL中进行任何重要的处理都会很快变得乏味和难以阅读。