数据库类型应用程序 中间件 设计 研究。

数据库应用程序按照其所具有的层次一般分为C/S、N-Tier，C/S 结构即是通常意义上的客户端/服务器结构，N-Tier就是近几年流行的多层框架结构。

本文即来讨论数据库类开发下多层架构的设计和开发。

一般的数据库类型N-Tier应用，一般分为3层，即客户端、中间件、数据库。我们在工作过程中也应用过4层模式，即客户端、中间件业务层、中间件数据访问层、数据库，这种模式实际上也是变形了的3层模式。

实际开发过程中，由于数据库类型应用程序开发的特点，我们实际上没有那么多业务需要交给中间件业务层来帮助完成，最后中间件业务层退化成了客户端和中间件之间的一个只起交接作用的层，只起到查询语句和更新语句组织的作用。最终，这个业务层中间件充斥了大量的查询语句和更新语句的组合逻辑。而由于客户端每次修改或增加新的功能需要修改或增加新的语句的时候，我们就要在中间层中修改或增加接口，最终中间层形成了一个上百乃至上千个接口的庞然大物。到最后，不论是要想复用代码或者是修改其中的代码都是一场恶梦。

在很多软件企业中，中间层的维护时交由专人负责的，客户端开发人员需要增加或修改接口都要先联系中间件维护人员。这种情况下由于软件开发的特性就会造成客户端开发经常需要等待中间层开发完成的情况，在等待的过程中造成了软件开发的不连贯性，甚至造成软件开发周期增长。当然也有很多企业是讲中间层的代码也同时交给客户端开发人员，由客户端开发人员自行维护中间件，这种情况下容易造成中间件开发参差不齐，中间件的稳定也成为很大的问题。

在上述种种问题的作用下，相当企业的多层软件开发者出现了抵制三层的情绪，认为多层架构没有给软件开发带来任何好处，不仅没有好处还带来了很多副作用。很多软件企业也退回了C/S开发模式，已经使用多层模式开发完成的软件业成为了鸡肋，维护过程中更是出现将查询和更新语句组织好只是使用中间层代理执行一下的行为。

最初，软件企业使用多层架构开发应用程序一般出于下面一种或几种考虑：

1、跟风，盲目使用新技术；

2、为了减少数据库连接；

3、使软件代码在多层架构下尽可能复用；

4、... ...

实际开发过程中，多层架构遇到的问题是：

1、接口众多，因为在接口的树林中找不到合适复用的那个接口，我们每次都创建新接口；

2、现阶段为减少数据库连接的需求已经不大，我们的服务器已经足够强劲；

3、我们的数据获取、保存逻辑一点没有简化，只是都放在中间件中了，甚至写起来更复杂；

那么我们有没有可能设计一种中间层解决上面的问题呢？答案是肯定的。

1、将所有的查询语句从中间件中分离，让中间件可以动态的从配置文件或者数据库中加载查询语句，然后根据客户端传入的条件组合成合法的查询语句执行查询，并将结果返回给客户端。

2、将所有的更新语句从中间件中分离，让中间件可以动态的从配置文件或者数据库中加载更新语句，然后根据客户端传入的修改数据组合成合法的更新语句执行更新，并将执行结果返回给客户端。

这样，由于SQL语句的分离，使这些语句集中保存，可以得到下面的好处：

1、技术负责人、DBA可以单独查看语句，优化语句，配合语句管理工具，语句管理更简单；

2、客户端不需要处理任何查询和保存逻辑，只要关心客户端的具体功能设计即可，设计效率可以提高10%；

3、中间件极为简化，只有2-3个常用接口，语句复用度高，由于设计简化同时也提高了可靠性、稳定性；

下面是我们基于上述理念开发的中间件的一个演示:
http://middleware.i-7cai.com:8080/Demo/iDMiddleware_AccessDEMO.zip
将来有机会，我将披露这个中间件更多的技术细节。