面向对象，真的必须设计数据对象吗？

开发：JAVA

 

现在越来越觉得自己把dao或者是orm看得太重了，认识到对于一个公司成功的系统，他们都必须有适合自身的存储系统或存储服务，他完全是为了业务或者说是Service而存在的;WEB2.0中涌现出来的新问题和新思想，为了解决暴涨的数据和用户，最耀眼的无非就是NoSQL，业务的成功背后的功臣它功不可默。

 

这里想表达的就是orm适合（结构简单稳定的，如果业务域对象复杂且多变是不适合的）和小用户量，一个成功的业务其后有一个适合业务的存储在支撑

 

 

常见的编程中，一直把面向对象当成神剑，在设计时领域模型非常重要，对应一个个的数据库表和java实体对象

 

心中一直在想这个（数据库表和java对应的实体类）真的是必须的吗？

 

感觉面向对象设计重点不应当集中在存储这一块（这个只是个人的经历，发现经历过的项目基本上都是面向对象设计都是集中在这一块），面向对象设计的重点应该在实现业务和业务的沉淀发展上，经历的项目很多都缺少业务上的对象设计，其实业务过程、业务状都可以设计的。

 

用多了ssh，感觉一直纠缠在orm上，忽略了业务设计，反倒让业务变成了简单的po = get()-->edit po-->saveOrUpdate(po);实际上对于业务系统，这样的设计太一般化，业务有时候迁就底层，反而使得业务不清晰，无法把以往的业务经验提取、积累发展，因为我们离开存储就什么都做不了。

 

难道是ORM把我们绑架了！

 

首先对于简单的系统，业务少的系统，ssh确实已经足够了，这个是他们的优势

 

在能源行业中，业务数据量非常大，业务复杂，需要满足业务的个性化非常多

 

最近几年随着WEB2.0的兴盛，正处于壮年的关系型数据库不能满足需求了，NoSQL提出了一种新的可能对于大量的数据没必要按照以往的方式存入关系型数据库，可以设计自己的存储结构和存储系统，可以依赖关系型数据库、也可以是自己的存储。

 

所以：个人觉得大数据量和业务复杂的系统应当根据自身数据的用途和特色设计适合业务的存储结构和存储系统。

 

在能源行业中，以往我们都是数据直接存储在同一个关系型数据库中（一般部署在小机上），完全可以构建符合自身需要的存储结构和存储系统。

电力系统中：

采集数据：对于采集上来的数据结构化非常明显，而且数据量非常大，此为原始数据，永远不会改变

业务数据：对于采集数据进行加工形成业务数据，基本上此数据变化非常少

档案数据：档案数据（包括设备参数）变化比较频繁

 

采集数据： 稳定（5年不变） 数据量大（百万记录/天） 查询简单（<3s） 因查询简单 索引就可解决性能问题

业务数据： 随业务变化 数据量大（百万记录/天） 查询复杂（<3s） 复杂的业务索引不能解决性能问题

档案数据： 随业务变化 数据量小（百万记录/生命期） 查询复杂（<3s） 复杂的业务索引很难解决性能问题

 

对于以上数据我们完全可以根据各自的特色构造符合自身的存储或服务系统：

档案数据： 数据量少，完全可以加载到内存进行全内存处理，存储时直接使用完善的关系型数据库。

采集数据： 基本上是只读数据，且结构稳定；完全可以设计一个稳定的分布式服务系统；

业务数据： 大多数数据非常稳定，少部分数据属于业务数据，可能最近1个月内变化频繁，但是1个月前的数据都是非常稳定的，可以结合前面的《采集数据》来扩展设计一个分布式服务系统

 

我们可以把存储进行分散，把解决性能瓶颈的任务和责任分布到不同的子系统，业务系统不再关注基础数据（采集数据和业务数据）的存储和查询的性能，他们只要专门做业务就好了。

 

小型机的采购和维护费用非常高，完全可以降低下来，对于档案数据可以采用oracle做一个可靠的系统，机器普通的server就够了，现在的WEB2.0站点的经验，采集和业务数据可以适当考虑使用廉价的存储和机器就可以满足需要，数据也可以保存到mysql等这样廉价的数据库中。

 

构思数据的存储系统，为了满足大量数据的存储和查询而做^ ^

 

各位兄弟，期待您的建议和探讨 ^ ^

谢谢:)

 

 

 

 

评论

2 楼 skzr.org 2010-09-29  

还需要更多实践，最近做一个自己的东西，本来为了偷懒使用hibernate，现在越来越发现为了实现一个设计，不得不迁就hibernate，如此还不如直接使用jdbc！

打算全面替换orm，回归最原始的dao设计——前几个月一个同事说的：我们既然用了oracle或者mysql，就应当使用它的特性来简化数据的存储或者操作。现在深有感触了

现在尝试设计一个大数据量的存储和服务的系统

实践出真理！！！

1 楼 Mybeautiful 2010-09-29  

引用

感觉面向对象设计重点不应当集中在存储这一块（这个只是个人的经历，发现经历过的项目基本上都是面向对象设计都是集中在这一块），面向对象设计的重点应该在实现业务和业务的沉淀发展上，经历的项目很多都缺少业务上的对象设计，其实业务过程、业务状都可以设计的。

严重同意，的确如此。

其实如果我们把ORM需要的所谓实体Bean,看成数据存储领域，完全不看作是业务逻辑有关。这些Bean的存在只是为了更加方便的操作数据。所以就让这些实体bean不“面向对象”吧。如兄所言，面向对象应该是在放在业务领域。