拼接“SQL字符串”的烦恼

Question

在查询的时候，发现很多现在的项目的框架都存在“拼接SQL字符串”的现象。最常见的就是生成“报表和图表”的时候，根据不同的条件“拼接Sql语句”，能拼接到几张A4纸那么长。个人认为，如此“拼接Sql”字符串，不好调试，而且费时费力。有没有什么好的方法，可以避免拼接“Sql字符串”，解决这个烦恼？？？比如使用：“Linq  to   Sql”可以吗？？？  
主要是因为涉及到“Silverlight”在“Asp.net”项目中的使用，要用到“RIA  WCF  Service”。
 

Answer 1

值得关注，应该学习。Orm，NHibernate...

Answer 2

存储过程啊，大量的拼接SQL效率很差的！

Answer 3

参数化sql语句，或者用参数化存储过程。

Answer 4

用“Entity Framework”可以吗？好像“Access”不支持的对吧？？？

Answer 5

借一下，“hzzasdf”的回答，说的很清楚了。silverlight无非是用web service来访问服务端（ria service无非是系统自动生成web service的代理类)，至于ef, ado.net都是访问数据库的方法，跟ria service一点关系没有。我公司的silverlight项目，访问数据库，用ef和ado.net都有。无非是ef直接返回对象，ado.net要自己把dataset转换成自己需要的对象罢了。

Answer 6

LZ，把几张A4纸的拼接语句拿出来SHOW下，很好奇啊。

Answer 7

报表的话 
可以考虑先将需要的数据缓存起来。然后在程序里通过Linq进行筛选数据。类似于:DataTable dt = new DataTable();
        var query = from data in dt.AsEnumerable()
                    where data.Field<int>("ID") == 1 && data.Field<string>("Title") == "test"
                    select data;

Answer 8

是的，现在用的好像是“Session”,如下：
//取得统计数据
 var data = GetMonitorDatas();
//缓存以备后用
Session["PowerMonitoringData"] = data;这是在“asp.net”中的，在“Silverlight”下怎么办呢？

Answer 9

谢谢大家一直以来的帮助，现在明白了。“ADO.net”（连接字符串类/Adapter类，两种方式）、“Linq to sql”、“EF”这些都是访问数据库的方式，是DAL层，而“RIA WCF Service”是BLL层，是这样的吧？？？还有两个问题能和大家确认下吗？1、Access下不能使用“EF”，只能用“Linq to Sql”，以此来直接返回“数据对象”，被SL使用，是这样吗？2、EF的核心“EMD”（“edmx文件”），一个“edmx文件”好像可以包含好几个“实体类对象”，只要在对应的“数据库表”上面打上勾好像就可以生成了，是这样吗？

Answer 10

追加一个问题：3、就这样一句

[EnableClientAccess()]
  public class OrganizationService : LinqToEntitiesDomainService<AdventureWorksEntities>
  {“EF”和“RIA WCF Service ”就结合在一起了？

Answer 11

少量字符串拼接，用 +
大量字符串拼接，可以考虑使用4.0的新东东：string.Concat,很高效

Answer 12

1.EF只是一个ORM框架，Linq to Sql跟数据库没有关系，它只是能让你像写SQL一样操作内存数据。
2.EF提供很多方式供开发者使用，你说的这种是数据库驱动（也就是根据已有数据库生成实体模型，这时候包括DBContext都是生成的）。但是这种不够灵活，一般不使用，更多的是
Code First，先写POCO实体，包括DBContext都要自己写，在来根据这些实体模型生成数据库。

Answer 13

如果SQL真的能拼接到几张A4纸那么长！！！！ 那我建议你还是拿字符串拼好了....

Answer 14

拼接SQL有拼接SQL的优点，是最客易调试的方法

Answer 15

现在的项目中就是使用“StringBuilder”，来拼接的呢？

Answer 16

谢谢您，谢谢。问题一：“Linq to Sql跟数据库没有关系，它只是能让你像写SQL一样操作内存数据。”，“Linq to Sql”  不能作用于数据库，实现“增、删、改、查”？？？问题二：“根据这些实体模型生成数据库”，数据库根据实体模型来生成？？？那要是已经有了数据库了怎么办？问题三：自己要用的“实体模型对象”来自于多个表，也就是“多个表的字段”作为“实体模型对象”属性。而不是根据数据表自动生成的“edmx  实体模型”是不是就要使用“POCO实体”？？？

Answer 17

生成报表这种需求，功能很简单，但是又很多变，用拼接字符串这种弱类型的编程方式是程序员最喜欢的方式。
要用linq也可以，就是这些条件表达式都要转换成表达式树，虽然强类型了，更优雅啦，但是实际好处并没有增加什么，反而把代码弄的很复杂，而且下次修改统计需求了，很可能还要修改代码。把拼接sql语句的函数写的好一些，通用一些，字段名什么的都加上中括号，拼接的时候一步步拼接，一步步调试，应该能完成任务

Answer 18

也就是说拼接“SQL”在报表生成方面，还是很有优势的对吧？

Answer 19

“表达式树”人家也要拼接字符串啊。而且你要调试sql语句的时候，怎么跑到表达式树上去调试？此时可能你根本无法调试，根本不知道最终的那个sql是什么！

Answer 20

我想你还是考虑这种调试，以及这种报表是不是该扔掉吧。为什么你要去调试什么sql语句？sql语句应该是隐藏在底层的，就好象我们编写c#代码是从来不用去调试什么汇编代码一样。如果果真需要你去调试什么sql语句，或者这种报表的功能设计比较业余（它竟然要你去搞什么低级编程），或者是它质量太次了经常有自身产生的底层代码中的bug。

Answer 21

越是灵活的系统，越是大的平台系统，月要注重高强度的自动化测试设计，而不是搞什么调试。实际上当你采取测试驱动方式去开发的时候，一个很简单的原则：“假设注释掉代码之后测试程序仍然可以通过，那么这个代码就可以一直注视下去甚至删除了！”。这样你每一次修改、扩充、除错、重构都是仅仅针对少数几条代码，你几乎不用调试就可以立刻知道哪里有bug需要修改，然后迅速按F5启动测试程序就行了。很少用调试。号称自在写一个通用的、灵活的引擎程序的人，如果跟我说他整天发愁调试问题（而不是测试用例设计问题），我对他的程序也不会太感兴趣。如果你去下载一些开源程序就会发现，每一个程序里边都会有至少一个测试程序、内含几千个测试用例。人家的产品的发布是带着测试程序一起发布的。这样就不会纠结于调试问题。善于自动测试的程序，很少需要花时间去调试。

Answer 22

顶~！其他楼上说的那些估计都是针对特别案例的
平时复杂交叉模糊查询的程序多了去了，难道都要用他们这种方法？
所以还是简单的用+，稍微多的用StringBuilder吧。今天看了一篇Java大师级文章，说的就是这种问题现象，其中他说道短的用+，多的用StringBuffer