我觉得ITEye的回复管理不好用,或者是我用不好这个功能,所以如果回复内容较多的时候,还是单独写一篇吧。
首先要说的是 jinnianshilongnian你老兄太客气了,你觉得我的说法不对就直说,归根到底,我们只能根据已有的经验,说一说自己的看法,对不对,都需要多听取别人的看法,来完善自己的认识,所以说欢迎大家的指教,这是帮助我成长,改正我错误的观念。
一般我认为,因为系统复杂,所以要“挫其锐,解其纷”进行复杂度分解,分解之后的每一个部分,都不会还是盘根错节,那么复杂了。当然,这只是我遇到的情况。
我赞成你的“对业务对象建模”这一说法,根据业务的需求和逻辑,分析业务对象和业务对象的各种行为、交互,是系统需求分析和设计阶段最重要的事情。我的说法,这个时候不要把数据库和ORM这东西引入进来;甚至说,连想这方面的事情都不去想。
你对框架和工具的理解我完全赞成。在进行产品开发时,有时候会选择一些框架(可能是选择外部开源的框架例如Spring等等,还有可能在开发组内部一些人开发自用的框架-----几年前我就是主导框架部分开发的,所以对框架和工具之间的区别比较清楚,呵呵,见笑);有可能会选择一些工具,例如Google的Guava、JDK的并发包、Apache的Common等等。
我自己从事框架的设计开发以及产品设计时,有一个感触,所以催生了更愿意把ORM当成“工具”而不是“框架”,就是因为框架和工具的这个区别,选好框架后,自己做具体实现,挂到框架中,你要跟着框架的思路来走;工具是随你自己需要提供低一层的功能,思路是由自己主导的。框架从快速开发的角度,非常有利于快速开发(针对一些时间紧的项目是这样最好),但是对需要长期不断完善、改进、精雕细琢的产品来讲,第一个版本的开发,只是万里长征的第一步,所以这时候开发的速度并不是最重要的。
有点跑题了,说回ORM,我的业务层的业务对象之间的逻辑关系都已经设计和实现好了,只是对象->数据库和从数据库里取出来制定的业务对象还没有实现,这时候,我需要一个工具,能够按要求把这些功能给实现了,如此而已。所以,从这个角度我说ORM最好只是一个工具。就像上篇文章里引用的文字的说法。
说到你提出的ORM干扰设计这个说法,其实我上篇文章表达的不好,并不是说ORM这东西本身怎么不好,干扰什么设计,而是很多人,只是为了自己省一些代码工作量,为了有一些“免费的午餐”,对ORM这东西的滥用,对设计造成了干扰。
我觉得对产品设计来讲,先设计数据库,然后从数据库表产生代码就是一种不好的设计和开发实践,造成了OOD的过程从设计数据库表结构开始;先设计对象,再通过注解产生数据库表结构呢,的确要好很多,看上去OO了,但实际上,大多数时候不能很好的利用数据库的特性,因为我经历过很多项目和产品,数据库的设计,客户要求一定要和他们的DBA协商确定的,根据自身的业务对稳定性、性能和维护方便的要求来设计的,不可能由产品开发设计人员完全确定。
你说的很对,要根据情境选择合适的工具。一般来讲,选择之前,先应该摒弃“省点代码,省点时间”和“找点免费的午餐”这些想法,再来选择或设计自己的技术路线和工具、框架。
对 dwangel 的回复
楼主做的系统不够多,涉及的数据类型没有达到一定的数量级。
的确,我做的系统不够多,但是我做的系统也是在客户那里7*24*365运转,每天承载全国的业务;涉及系统数据类型没有达到一定的数量级,这是工作特点决定的,所以我的确有井底之蛙的嫌疑,我也愿意大家把自己的经验讲给我,让我增长见识。
还是那句话,系统在设计时,应该先进行子系统分解,然后是模块分解,如果分解了很久,每个模块还是异常复杂,数据类型、业务流程和业务对象之间的关系还是那么复杂,那么我觉得业务的分解过程做得不是很好。架构设计的一个重要任务,就是把系统的复杂度分解到各个子系统和模块,每个子系统和模块都承担一部分复杂度,再协作完成系统的工作目标。你分解了半天,每个子系统和模块还异常复杂(甚至涉及的数据类型还都是成千上万的,是不是有问题
而且不是大团队作业。
团队作业又怎么样呢?大的团队,上百人一起工作,其实也无非是分割成一个个小团队来做,甚至小团队内部再划分成几个组来进行工作。团队建建立起良好的工作(设计和编码等)规范和制度来降低沟通的成本,或者建立星形的沟通结果,避免网状沟通。这一点是人的问题和管理的问题,和任何技术选型都是无关的。
当然,框架本身的确包含了一定的设计规范在其中,这是无可非议的。
你说的业务对象建模没有问题,只是此“业务对象”是和数据库无关的,跟ORM更无关。在使用业务对象搭建系统完成之后再来使用ORM其实也是很好的。
回复Allen:
我没有这个意思,我很讨厌把业务逻辑放在数据库里。别人怎么设计我不管,我设计系统时,业务逻辑一定要放在程序代码中。这篇东西本身就是为了表达自己对ORM的看法,以及对“ORM已死”这个说法的一些思考。
相关推荐
能实现基本的数据库操作能实现基本的数据库操作
ORM框架 C#.NET ORM框架ORM框架 C#.NET ORM框架ORM框架 C#.NET ORM框架ORM框架 C#.NET ORM框架
Sqlite ORM 是一个简单的C#类,对Sqlite的操作进行了封装,主要功能包括:表定义、生成,访问,更新等,其中,支持,多表的连接操作,语法类似Linq语法,使用非常方便,附加了使用说明文档。 例如,添加记录操作为...
这里面包括了Hibernate和MyBatis的实现ORM思想的原理,以及讲解了什么是ORM思想。仿照Hibernate自定义了一个简单的增删改查的ORM框架,还有测试代码。
对orm框架的详细分析 适合初学者 很有用哦
orm4es是一个Elasticsearch的ORM工具,它可以生成简单的查询对象.它本身非常简单,也很容易使用;代码生成通过freemark完成,它会自动解析es index 的mapping设置,根据mapping生成与index对应的java Bean,使用生成...
ORM对象关系映射。。ORM对象关系映射。。太详细了。。最全的介绍。
自己写的ORM,看看大家给几分
ORM映射与WEB的应用ORM映射与WEB的应用ORM映射与WEB的应用ORM映射与WEB的应用ORM映射与WEB的应用ORM映射与WEB的应用
简单易用的基于SQLite3的C++ ORM框架
工具简介:自己实现的简单的ORM工具,使用到的技术:JDBC+java反射机制。 简单的文档:rar解压后,DOC目录下:K-ORM.DOC
ORM工具测试比较,包含Ado.net,EF,Dapper,Subsonic,LinqToSql,DAAB,可以直接数据库附加后,测试比较性能,支持自行修改代码调试。小项目可以选一种直接使用。
spring-orm.jar
简单讲述orm使用,对于学习orm的很有帮助。
Net下ORM框架概述,仅供参考,ORM是企业开放的热门技术
选择Dos.ORM的理由: 1.上手非常简单,0学习成本。使用方便,按照sql书写习惯编写C#代码。功能强大。 2.轻量级,只有一个dll文件(不到200KB),相比于EF,NHibernate这些重量级的ORM框架,实在是太小。 3....
这是很经典的 dao orm 方法 魔乐技术2008的经典
系统架构+ORM+设计模式 系统架构+ORM+设计模式
Dos.ORM 代码生成器 实体生成器
SqlSugar ORM工具箱2.2.7z