在Ruby on Rails/Naked Objects精神指引下的域驱动开发框架

banq

非Java体系的ROR对Java领域产生强有力的震撼，如何更快更方便地开发J2EE是Java开发者首要关心话题，Naked Object又对权威提起挑战，否定之否定推动技术的进步。

http://www.jdon.com/artichect/ror.htm

mythmoon 2005-07-16 20:35
没有优秀的开发工具支持,在好的框架也白搭!
微软web form 就是很好的正面例子,想象一下没有优秀的开发工具,web form 用起来也麻烦哦!


_________

mythmoon 2005-07-16 20:37
软件成功不是技术NO.1,更重要的是用户NO.1所以谁也挑战不了微软,sun也是,java也是!
banq 2005-07-17 08:12
>没有优秀的开发工具支持,在好的框架也白搭!

优秀的开发工具也会成为阻碍技术发展已经系统灵活架构的绊脚石，这个问题是相对的。 所以我们现在已经不期望通过工具来简化开发，因为这必然会伤害到细腻松耦合的架构；只有可能简化设计架构，工具这些实现才有用武之地；工具是为架构实现服务的；

这里讨论焦点实际是：Domain Object或BO到底是被业务层Service遮挡（SOA）还是直接暴露给前台（naked object），这篇帖子对这个问题进行了讨论：
关于BO的问题

另外，微软的Web服务WebService也是属于一种SOA，是使用Service遮挡Domain 的架构，这样才能实现服务共享。

zhuam 2005-07-18 13:16
其实这也不是什么新的概念和方法, 这是很普通的开发方式啊, 这种方式对OO的设计能力比一般的POJO + Service + DAO + ... 的开发方式要高, 这也是领域建模的真缔啊!

曾几何时我也是经常写POJO,但现在根本不同, POJO + SERVICE 有很大的弊端, 这记的robbin 好像总结过三种当前的java开发模式, 这算一种吧!

还有就是JDON FORMEWORK 一会儿是IOC ,AOP ,一会儿又是这样, 什么热你就有什么,不懂, 这样反而会将该formework 搞的不成样子,任何东西都有他自己的个性,不能多而不精!

ziyi 2005-07-20 09:14
关于是否需要service layer，在MF的《企业应用架构模式》中有很好的阐述。大概意思就是当我们的应用有分处应用逻辑（比如工作流处理，事务的控制）跟业务逻辑的时候，就要这一层，还有当我们的应用可能被其它应用调用或者我们会掉用其它应用的时候是需要者一层来支撑的。
还有吧，看过很久了，记不得了，对偶们这些菜鸟而言，说的还是可以的。反正也比较能够接受这一层的思想，好处多于坏处吧，对一个企业来说关键在于针对某种框架的积累，能够熟练的应用此框架进行开发，至于banq说的那8大步骤我觉得可以在积累中慢慢的针对某些步骤进行一些自动化的处理，似乎治标不治本:)
vcshcn 2005-07-27 16:12
感觉这个问题和"是否使用贫血"的含义差不多.
谁能权威回答一下,是否该使用贫血呢,我已经迷惑一年了
我见到过大量的不使贫血的,包括很多有名的系统,但也见到过很多使用的.
cj 2005-08-10 15:34
过眼烟云 2005-10-10 00:58
you didn't list the steps for 直接暴露给前台. I'd like to know which steps are elimated.

被业务层Service遮挡:
1. 创建Person类.
2. 创建PersonDAO类.
3. 创建Person数据表.
4. 定义PersonDAO在Spring的application context XML文件.
5. 创建Person page页面和action类.
6. 增加Person页面到web框架(如struts)XML配置文件中.
7. 创建personList页面来显示Person实例.
8. 创建personEdit页面来编辑Person实例.

还是直接暴露给前台:

?