即然选择了多层架构，但要做到最好，每一个拼写SQL语句的地方，都应该对应一个业务逻辑方法。所以前期做好需求很重要，先定义接口（能想到的所有逻辑），然后再实现接口中的方法（参数传递，避免SQL注入等）。

表现层

业务处理层

数据罗辑层

数据层

把你的拼SQL写到数据罗辑层

你可以把所有SQL都放在一个配置文件里，写一个从配置文件读取SQL的方法，格式类似

 <SQL id="GetItem">
<![CDATA[select col_name_zh ZBName, db_field ZBKey 
      fromTFM_ALARM_COL_INFO_BJ
      where entry_flag = {0}
      order by zbname]]>
    </SQL>

至于参数entry_flag = {0}
就可以直接用string.Format()方法了，这样就算放在表现个层，sql也是封装好的

我是这么进行设计的，并且遵循以下原则。

1. 首先，我依旧必须保证整个项目的面向对象性。
2. 我必须保证整个项目的分层性。
3. 我必须保证“让类库的使用者方便，而不是实现者方便”的原则。

因此，如果不确定查询很复杂的话，我会在系统中设计以下的类。

GreaterThanOrEquals、Equals、LessThanOrEquals、And、Or、Group（用于 Where 语句中的括号情况）、Like 等等所有在 Where 语句中会用到的操作（或者一个子集）。

在后台，分析这些类，并且解析成 SQL 语句。

分层主要是为了体现逻辑独立性，即高内聚低耦合。不该出现在这个层的东西就不要让他出现。这样以后你换数据库，或者改前台就会很方便了。

不过我建议你不要用拼接字符串的方法。你可以将语句写入数据库，用的时候调用存储过程就好了。这样更安全，更方便。