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

原创 2007年09月18日 11:54:00
一个类对应数据库中的一个或多个表
永远不在应用程序中使用SQL语句
从数据库出来的就是实体信息
ORM在数据库内做更为合适


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

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

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

1"获取需求没什么说的

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

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

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

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

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

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

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

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

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

相关文章推荐

iOS数据库离线缓存思路和网络层封装——数据缓存操作封装

使用说明  1 关联第三方库  1-1 FMDB  1-2 LKDBHelper .h文件 #import #import "LKDBHelper.h" @interf...

林峰:大数据安全新思路

  • 2014年05月29日 14:08
  • 2.15MB
  • 下载

iOS数据库离线缓存思路和网络层封装——数据缓存机制Model封装

.h文件 #import #import /// 缓存策略 typedef NS_ENUM(NSInteger, NetworkCacheType) {     /// 无视...

mysql数据库优化--选择合适的数据类型

选择数据类型的基本原则

Excel导入easyui dataGrid数据批量保存新思路

 dataGrid数据批量保存,如果是一位老司机可能要这么做: 第一步、先把数据从excel读取,然后转化为json格式 第二步、把json数据JSON.parse(jsonDa...

Kubernetes排错:用容器的元数据提供新思路

在这篇文章中,让我们讨论一下Kubernetes中的元数据(Metadata),以及如何利用它来监控系统的性能。 元数据(Metadata) 是一个较为高大上的词。它的含义是“用来描述其他数据的...

【我要写框架之导入Excel数据至数据库】——思路整理

说明 背景: 导入Excel数据到数据库成为目前项目中很常用的技术,整理以前的实现发现:在原来系统中的导入,没有实现方法复用,如果要实现某一处数据的导入,需要将原来的代码复制过去、修修改改,实现过程较...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:数据层新思路,写数据库无关的数据层 ORM在数据库内做更为合适
举报原因:
原因补充:

(最多只允许输入30个字)