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

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


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

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

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

1"获取需求没什么说的

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

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

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

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

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

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

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

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

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

相关文章推荐

林峰:大数据安全新思路

  • 2014-05-29 14:08
  • 2.15MB
  • 下载

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

选择数据类型的基本原则

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

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

浦发银行大数据库表备份设计思路(数据泵)

经常会遇到数据量很大的业务表导入导出时把数据库导挂的情况,利用oracle特性可以有效解决。

数据库中两张表之间的数据同步实现思路(增加、删除、更新)

分别创建增加、删除、更新的触发器(Trigger)来达到两张表之间数据同步的目的。 1:数据同步增加: 如有两张表——A表和B表,创建触发器使当A表插入数据后B表也同步插入数据。其中B表插入数据的...

关于多数据库的数据汇总时的各种思路

一.纯粹的数据整合 如果不存在多库数据排序的情况下,只要将多库的数据整合到一起分页即可。做这种需求的时候先后想了以下的解决方案。下面均以A,B两个库举例。 1)把A,B库的数据全部取出来...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

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