|
精华帖 (1) :: 良好帖 (11) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-09-13
zwchen 写道 ltian 写道 楼上说的没错，十几年来，基于dataset开发的软件系统一直都有那样问题，不仅如此，系统之间的集成（数据和应用集成）一直很差。所谓面向对象模型的不稳定和易碎是单纯从技术角度考虑问题而不考虑业务的程序员得出来的不全面的结论，很多程序员梦想开发一套什么动态的系统来解决这些问题，最终把编程技术高度抽象为对数据集的增删改查。这是沿着一条错误的道路勇猛之前，如果那条路可以走得通，Delphi，VB等早就解决了那些问题。这是与我所看到的国际的主流信息化建设思想完全背道而驰的错误思路。在物联网，尤其是智能电网建设的大背景下，欧美一直将重点放在开发稳定，通用的基于面向对象描述的业务模型，他们为此开发了大量的标准，覆盖了人、财、物、客户、组织、费率、工作排程、资产、价格、设备、智能楼宇、智能表计等很多方面。
如何能够更好地利用面向对象来解决问题，我建议读一读四人帮的设计模式，这是最基本的，之后，根据需要看看这些网站提供的面向对象的业务模型： http://www.opengroup.org(开放群组官方网站) 包含很多通用业务模型。 http://cimug.ucaiug.org（智能电网—CIM用户群组官方网站）CIM模型，电力领域，并引用了其他领域通用模型。 http://www.iec.ch/ （IEC官方网站） CIM模型，电力领域，并引用了其他领域通用模型。 http://www.mimosa.org/（机械信息管理开放系统联盟组织官方网站） 资产、设备维护模型。 http://www.cim-ple.com/ （CIM模型研究网站） CIM模型，电力领域，并引用了其他领域通用模型。 http://www.oagi.org/dnn2/(开放应用群组官网站) OASIS模型，人财物领域。 http://www.opengeospatial.org/（开放地理信息联盟官方网站） 地理信息模型。 以上观点仅从个人经历出发，可能偏面，请大家批判。 我之所以废弃原来那种框架设计方法(我没有在文中链接到到该文章)，也是意识到复杂业务系统，必须有清晰的、静态的、稳定的领域模型，比如社保、货运等领域模型，10年可能都不会有多少变化。而且，从技术实现角度，企业应用偏向于写操作，弱类型的数据操作业务一复杂就很容易失控，因为没有约束检查机制。 所以，eXtream那种数据管道模式的偏技术实现的框架，我觉得也不太适合企业应用开发，尤其是大团队协作式开发。 当然了，对于偏向互联网网站这种以读为主的业务场景，弱类型还是有优势，比如Spring JDBC + Spring MVC + EL这一套。 是的，赞同你的看法，领域模型驱动开发需要一批有经验的人去推动，否则在企业应用开发领域，中国仍只能是低水平地重复开发，愿与诸君共同努力。 |
| 返回顶楼 | |
|
发表时间：2011-09-13
ltian 写道 zwchen 写道 ltian 写道 楼上说的没错，十几年来，基于dataset开发的软件系统一直都有那样问题，不仅如此，系统之间的集成（数据和应用集成）一直很差。所谓面向对象模型的不稳定和易碎是单纯从技术角度考虑问题而不考虑业务的程序员得出来的不全面的结论，很多程序员梦想开发一套什么动态的系统来解决这些问题，最终把编程技术高度抽象为对数据集的增删改查。这是沿着一条错误的道路勇猛之前，如果那条路可以走得通，Delphi，VB等早就解决了那些问题。这是与我所看到的国际的主流信息化建设思想完全背道而驰的错误思路。在物联网，尤其是智能电网建设的大背景下，欧美一直将重点放在开发稳定，通用的基于面向对象描述的业务模型，他们为此开发了大量的标准，覆盖了人、财、物、客户、组织、费率、工作排程、资产、价格、设备、智能楼宇、智能表计等很多方面。
如何能够更好地利用面向对象来解决问题，我建议读一读四人帮的设计模式，这是最基本的，之后，根据需要看看这些网站提供的面向对象的业务模型： http://www.opengroup.org(开放群组官方网站) 包含很多通用业务模型。 http://cimug.ucaiug.org（智能电网—CIM用户群组官方网站）CIM模型，电力领域，并引用了其他领域通用模型。 http://www.iec.ch/ （IEC官方网站） CIM模型，电力领域，并引用了其他领域通用模型。 http://www.mimosa.org/（机械信息管理开放系统联盟组织官方网站） 资产、设备维护模型。 http://www.cim-ple.com/ （CIM模型研究网站） CIM模型，电力领域，并引用了其他领域通用模型。 http://www.oagi.org/dnn2/(开放应用群组官网站) OASIS模型，人财物领域。 http://www.opengeospatial.org/（开放地理信息联盟官方网站） 地理信息模型。 以上观点仅从个人经历出发，可能偏面，请大家批判。 我之所以废弃原来那种框架设计方法(我没有在文中链接到到该文章)，也是意识到复杂业务系统，必须有清晰的、静态的、稳定的领域模型，比如社保、货运等领域模型，10年可能都不会有多少变化。而且，从技术实现角度，企业应用偏向于写操作，弱类型的数据操作业务一复杂就很容易失控，因为没有约束检查机制。 所以，eXtream那种数据管道模式的偏技术实现的框架，我觉得也不太适合企业应用开发，尤其是大团队协作式开发。 当然了，对于偏向互联网网站这种以读为主的业务场景，弱类型还是有优势，比如Spring JDBC + Spring MVC + EL这一套。 是的，赞同你的看法，领域模型驱动开发需要一批有经验的人去推动，否则在企业应用开发领域，中国仍只能是低水平地重复开发，愿与诸君共同努力。 你们在讨论啥啊，看不懂 |
| 返回顶楼 | |
|
发表时间：2011-09-13
POJO同学?
让我想起了有本书，叫：POJO in action |
| 返回顶楼 | |
|
发表时间：2011-09-13
不管怎么变，反正经验是很重要的，实践出真知。
|
| 返回顶楼 | |
|
发表时间：2011-09-13
最后修改：2011-09-13
引用 从纯技术角度去提高软件生产力，微乎其微(人月神话大家都认同吧？)
这话我可不能认同。从我们的实践看，没有平台技术的支撑，开发现在的产品完全是不可想象的事情。不过，我们的开发平台是基于ORM的，而不是数据集的，并且大量利用了自定义的模板编译技术。数据集的一个问题是没有关联的行为，导致最基本的lazy都很难做，另外也缺少行为的封装，比如 o.x.y.z 封装为o.z。从框架层面上看，如果运行逻辑主要由框架完成，则框架操作强类型的对象确实没有什么必要，但是如果大量业务代码也完全基于数据集，多少有些利用不上已有的java机制。如果平台完全提供一个新的编程模型，同时不能充分利用已有的编程模型，这其中的得失一般就很难计算。我们的做法是尽量利用已有的各种可用的技术手段，比如java的继承，强类型等等，只是通过粘结层来实现各种编程模型的融合。 从 gwcsreg.7z 这个附件中的内容来看，这个框架采用pipe模式之后，导致代码组织形式与普通的面向对象设计有很大的区别，有些支离破碎的感觉。大量的代码之所以存在似乎都是框架内在的组装逻辑要求的，而不是很直观的业务描述。框架应该是将所有粘结性代码抽提出去，业务代码仅仅作为领域描述知识。 |
| 返回顶楼 | |
|
发表时间：2011-09-14
我现在不是经常登陆iteye，所以刚刚看见这个帖子。在这里先做一个简单的回应。
要理解我的想法，读者首先要懂XML。有XML支撑的数据集不是简单的Map。我在以前的某个帖子里说过，中国的程序员普遍地缺乏对XML的理解。 要理解我的想法，就像我在老帖子说的，读者可以用线性代数作类比。XML数据是业务空间的向量，管道化的处理结点就是矩阵。矩阵乘矩阵还是矩阵。这不就是高阶函数？谁说函数式编程非得依赖函数式语言？以这样的角度去看我的框架，数学图像非常清晰。清晰的数学图像意味着高度的抽象，远比OO的抽象程度要高。给你一个由电流，电压，电阻和功率描写的业务系统，如果你不懂物理，依靠OO，你会得出怎样的领域模型？这样的事情不是每天都在发生吗？ |
| 返回顶楼 | |
|
发表时间：2011-09-14
pojo 写道 我现在不是经常登陆iteye，所以刚刚看见这个帖子。在这里先做一个简单的回应。
要理解我的想法，读者首先要懂XML。有XML支撑的数据集不是简单的Map。我在以前的某个帖子里说过，中国的程序员普遍地缺乏对XML的理解。 要理解我的想法，就像我在老帖子说的，读者可以用线性代数作类比。XML数据是业务空间的向量，管道化的处理结点就是矩阵。矩阵乘矩阵还是矩阵。这不就是高阶函数？谁说函数式编程非得依赖函数式语言？以这样的角度去看我的框架，数学图像非常清晰。清晰的数学图像意味着高度的抽象，远比OO的抽象程度要高。给你一个由电流，电压，电阻和功率描写的业务系统，如果你不懂物理，依靠OO，你会得出怎样的领域模型？这样的事情不是每天都在发生吗？ pojo同学，我确实没有看到XML在你的框架中的分量，难道是你这个例子的限制？ 如果你的框架需要人理解矩阵、向量、高阶函数这些概念，莫非是给神仙用？现在，一般企业招一个普通的合格技术人员都不容易(除开北京上海)，你要那些做PM的怎么做“生产”啊。其实，技术人员就是工人(丝毫没有贬低的意思)，难道要每个人都技艺精湛吗？ |
| 返回顶楼 | |
|
发表时间：2011-09-14
canonical 写道 引用 从纯技术角度去提高软件生产力，微乎其微(人月神话大家都认同吧？)
这话我可不能认同。从我们的实践看，没有平台技术的支撑，开发现在的产品完全是不可想象的事情。不过，我们的开发平台是基于ORM的，而不是数据集的，并且大量利用了自定义的模板编译技术。数据集的一个问题是没有关联的行为，导致最基本的lazy都很难做，另外也缺少行为的封装，比如 o.x.y.z 封装为o.z。从框架层面上看，如果运行逻辑主要由框架完成，则框架操作强类型的对象确实没有什么必要，但是如果大量业务代码也完全基于数据集，多少有些利用不上已有的java机制。如果平台完全提供一个新的编程模型，同时不能充分利用已有的编程模型，这其中的得失一般就很难计算。我们的做法是尽量利用已有的各种可用的技术手段，比如java的继承，强类型等等，只是通过粘结层来实现各种编程模型的融合。 从 gwcsreg.7z 这个附件中的内容来看，这个框架采用pipe模式之后，导致代码组织形式与普通的面向对象设计有很大的区别，有些支离破碎的感觉。大量的代码之所以存在似乎都是框架内在的组装逻辑要求的，而不是很直观的业务描述。框架应该是将所有粘结性代码抽提出去，业务代码仅仅作为领域描述知识。 别和我较真嘛，纯技术很重要，我说的微乎其微，主要是指当前这个框架。 另外我补充一点，框架有两种，一种是技术框架，也就是我们所见的JSF、Hibernate等； 还有一种，就是针对产品或行业项目的业务框架，它是基于技术框架的，但有很多业务组件，如权限模块、菜单模块，还有针对行业的控件，如HR系统的员工表单。因为同一个行业的项目，往往有70%是共通的，所以将这部分提取出来，重用。这就是为什么在软件行业做了几年的公司，都有自己的框架。框架会限制开发人员的手脚，也降低了开发的门槛，所以很多开发人员觉得不爽。 大家可以了解一下SAP的netweaver，有大量针对行业的组件库。国内金碟、用友的业务系统，都有业务平台的概念，虽然普遍都很烂。 |
| 返回顶楼 | |
|
发表时间：2011-09-14
楼主很厚道
|
| 返回顶楼 | |
