三层结构里的查询问题，请指教！！！
　

---

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

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

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

 回复: 三层结构里的查询问题，请指教！！！
　

---

查询算不算业务，这种争论没有什么意义。我觉得到底把查询的逻辑放在哪一层里面好要视各种因素而定。在我做过的系统中，我们把所有跟查询有关的逻辑放在中间应用服务器层，我们认为数据库只是存储数据的地方，里面实现业务逻辑的代码应该简化到最少，除非实在是因为性能原因。
查询是通过中间层定义的接口来操作，也就是说，做client的程序员只需要知道中间层的接口就可以了。这种开发模式对系统分析员提出了较高的要求。查询结果缓存在中间层里面，这样可以最大限度地做到数据库连接可重用，可支持大量的并发用户。

 回复: 三层结构里的查询问题，请指教！！！
　

---

显然freeman99 的想法更适合3层模式的思想，我们必须要知道，业务逻辑是会改变的，理想状态下，将SQL摸版定义好放入数据库是很好的方法，但是，它却带来了业务实现的限制。对业务过程的修改可能导致整个项目设计的崩溃。这个风险很大，谁愿意去负责。

 回复: 三层结构里的查询问题，请指教！！！
　

---

分析一下两种方法的优缺点：
1、优点： 编程工作负荷小，简化了编程。
缺点： 不利于集中维护。容易导致系统混乱。不利于适应新的变化和功能扩展。
2、优缺点刚好和1相反。

简而言之，方法一是不可取的，只是一些想偷懒的人才会坚持。
　

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