数据层新思路，写数据库无关的数据层 ORM在数据库内做更为合适

一个类对应数据库中的一个或多个表
永远不在应用程序中使用SQL语句
从数据库出来的就是实体信息
ORM在数据库内做更为合适

凡是做软件设计的,都知道我们追求的目标是松耦合的.
就是说,最好是每个层互相之间的关联降低到最低限度.

以下是个人的一些体会，软件设计我们可以这么做

1"获取用户需求
2"界面设计
3"业务实体类设计
4"数据库设计
5"编码

1"获取需求没什么说的

2"界面设计,也没多说的。不过可能这个地方是变化最多、最难的部分。

3"业务实体类设计
这里就是经典的面向对象的分析发挥力量的时候
不考虑任何编码实现,仅从业务实际出发对商业逻辑建模
这个步骤对后期编码的最直接的结果是一堆类图

4"数据库设计
这里是我最想说的部分
凭什么一个类用一张表来映射?
类是我们面向对象分析出来的结果,因此在很多人的实践里已经充分证明类和表不是一对一的关系
并且,如果从大型项目角度出发,从数据库变更角度出发.表结构的变更是迟早的事情.
如果类和表是唯一对应的.那么在数据库表和业务类之间就形成了一种强耦合的结果
即使你用再好的ORM都不能解决这个问题的（难道数据表结构变化后重新映射？注意，即使类分析结果不变，数据库的设计也是很可能会变化的）.
ORM的精髓估计不在于简单的将一个表影射成一个类
或者将一个类到数据库里自动生成一个表

推荐的做法是,根据类的实际数据情况,设计数据库的各种表结构
然后.利用数据库的视图以及存储过程等各种数据库工具,提供一个可以被任何软件调用的数据访问接口，这些接口是直接对应面向对象分析后的类图的。
这些接口基本能对应所谓数据持久化的需要.

上面是我第二个特别需要指出的地方,数据库存储过程的使用决策依据.(过几天再具体写)

这个时候,我们已经有了数据库，一个非常好的关系性数据库，并且数据库对外开放了一系列的存储过程及视图，这些东西对外都是按照类分析的结果做的。因此可以非常好的完成对象的信息在数据库内持久化。
今后只要业务对象不发生翻天覆地的变化，那么数据库内的所有一切变化对应用程序来说就是透明的

而这里就是第三个主要猜想，ORM更合适在数据库内完成
数据库内的表从存储过程执行后，从数据库出来的时候，就已经成为基础对象了。

到了这一步，那么在应用程序内就真的实现了完全彻底摆脱数据库的非面向对象的纠缠。
只要简单的进行数据层对象和存储过程的关联就能实现数据库无关。

因为对应用程序来说，和数据库唯一的关系就是存储过程和视图。
除非你要把项目移植到一个不支持这些功能的数据库上。
即使那样，也只需要格外添加一个过滤得层次就足够了
除了要进行连接字符串的配置
应用程序的数据层代码基本是无需修改了