|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-02-27
我可能没有说清楚，model不是data container。
标题说的意思基本上是指试图用Model-Driven解决一切问题的想法。 data container是一种容器，所以不应当算作层，在我的概念中，层的划分也应当是按照其行为或者说职责来作为依据的。 OO关注的是行为。往往我们觉得麻烦，或者困扰的都在PO，VO等无有效行为的对象上。这些对象只是每个层里面自己使用的中间产物，所以，我觉得VO什么的可以不用，直接用data container，在不同层进行传递数据的时候反而更加方便。 另外，我发现很多时候用Object不用data container的理由是可以取名字。有趣的现象。 我读了你的文章，注意到一点，就是你们的客户把页面行为作为控制单位，而不是页面。非常同意这种做法。以页面为单位考虑，和以页面行为为单位考虑，虽然只是粒度的微小差距，但是结果会差别非常巨大。 《领域驱动设计》思想我稍微了解一些，这个也是一个粒度上的问题，但是我还没有把握到要点，就是怎么样算作Domain，怎么样不是。但是，我觉得这个是要和Component-based结合才会产生明显价值的。或许也是未来软件开发像机械组装一样生产的关键。 |
| 返回顶楼 | |
|
发表时间：2007-02-28
GMF
http://www.eclipse.org/gmf/ 以开发图形化工作流定制器来说，建模（各种节点、连接的模型），简单配置，就可以出来一个原型了 需要做的只是对细节的修改 小型应用或许可以向这个方向发展吧？ |
| 返回顶楼 | |
|
发表时间：2007-02-28
凝血神抓 写道 GMF
http://www.eclipse.org/gmf/ 以开发图形化工作流定制器来说，建模（各种节点、连接的模型），简单配置，就可以出来一个原型了 需要做的只是对细节的修改 小型应用或许可以向这个方向发展吧？ 简单的CRUD，简单的技术型Demo可以，但是，在实际项目中，都不会这么简单。 虽然说只是细节不同，但是正是这些细节可以把复杂度提高几个数量级。 |
| 返回顶楼 | |
|
发表时间：2007-03-10
basicbest 写道 首先说明一点，我也做过分析，也做过设计，也做过架构，也做过项目管理。当然，接触的项目可能不是非常大，但也是差不多几千万人民币的。也就是说我还算有点经验。
我有疑问的是为什么有人要用model产生UI这层的东西？？？ 比如xml+xslt的方式产生html。 假设xml给的是model。 为什么没有人这样做，我用struts来说，就是先做页面，然后产生form+action等等东西呢？？？ 如果数据模型（xml模式）相对比较稳定，如果只是显示，直接用xml+xslt=xhtml是方便的，如果要改动ui，只要调整一下xslt很方便的；当然不是所有场景都适合这样做 |
| 返回顶楼 | |
