三层结构里的查询问题

问：
　　我们公司用准备采用Com+技术开发应用程序，可在怎么实现上有了
分歧，主要矛盾在查询部分，分为两派：
　　1。一派认为查询只是简单的数据选择，提议把基本SQL语句存到数据库里的
一个表中，由客户端拼凑查询条件，在业务逻辑层再从数据库里把基本SQL语句读出来接到一起去检索数据，整个系统的查询都调用同一个查询接口。
　　2。另一派认为查询也是属于业务逻辑范畴，并不是简单的SQL语句拼凑，
应该分成不同的接口来实现，客户端只向业务逻辑层传一些参数，由业务逻辑层传回处理结果。

我们曾展开过激烈的讨论，觉得问题应该主要集中在下面几个部分：
　　1。查询只是简单的数据检索还是业务逻辑？如果是业务逻辑，那么第一种方式的业务逻辑实现是在数据库端还是应用服务器端。
　　2。如果采用第一种方式开发，那么对团队合作开发效果是否好？比如说各子系统之间的相互调用就必须公开自己的SQL语句，而不是提供独立的接口。
　　3。一个系统中视图的使用应该有怎样的原则？如果视图数量超过数据表的数量的话，对开发和系统升级有什么影响？

因为我们水平有限，谁也说服不了谁，只能请求援助了，不知各位大侠有何高见？

　　1、不管是否对SQL语句进行硬编码或序列化，它都是逻辑层数据访问接口和数据层之间的协议。
　　2、在关系数据库的三个模式中，SQL操纵语句的设计就是应用模式的设计。
　　3、使用三层客户服务器结构使你的应用程序更容易扩展和布署。
　　4、对SQL语句实现序列化是参数化设计的一个办法，但需要对数据访问接口充分的抽象和设计。
　　5、序列化后SQL代码存放在业务数据库里会增加逻辑层与数据层的耦合程度，不利于数据层的灵活布署。
　　6、SQL的序列化数据建议使用独自的参数化文件或本地数据库实现。
　　7、对于数据访问复杂性不高的应用，仅仅使用动态SQL代码，设计一个数据访问子层集中SQL语句就可以达成目的。


作者：linchangping    转贴自：www.umlchina.com