2007年忽然明白了那些文章的意义,感慨原来差距是这么大。。。。。。
顺便问一个问题,就是
DDD 中的 实体,值对象,服务,对应于四色模型中的哪三个部分?
(那本DDD的书还没邮到,实在忍不住只好先问问)
顺便问一个问题,就是
DDD 中的 实体,值对象,服务,对应于四色模型中的哪三个部分?
(那本DDD的书还没邮到,实在忍不住只好先问问)
关于DDD和四色模型因为都是对同一种事物进行辨识的不同方法,必然存在同一个事物在DDD和四色原型中有不同的表示方法,只是表达方式不一样,实际是表达的同一个概念。
如果这两个方法都掌握了,自然感觉到类似部分,但是它们不是必然对应的。
正如你文中引用的obert C. Martin 的一句话:
数据库是实现细节!应该尽可能地推迟考虑数据库。有太多的应用程序之所以和数据库绑定在一起而无法分离,就是因为一开始就把数据库考虑在内了。请记住抽象的定义:本质的部分放大,无关紧要部分的去除。在项目的当前阶段数据库就是无关紧要的;它只不过是一项用来存储和访问数据的技术而已。
我非常同意你通过这个案例试图说明:
优先设计业务层,将数据库层放在后边设计,并不是十分难的,恰恰相反,这种方式对于业务的理解,更加有好处。
对于持久层的设计,无论是采用JDBC,Ibatis,或者Hibernate,总可以找到一个合适的模式来将业务层与之匹配在一起。其实大部分情况是我们一定会知道预先使用什么持久方式,所以,预先设计出一个结合业务与持久的模式,也是必要的方法。
数据库仅仅是持久层的一种解决方案,即使它是目前最广泛使用的持久方案。但是,在设计我们的业务的时候,不要着急去考虑如何创建数据库,先把我们的业务逻辑设计清楚,然后再去考虑哪些类需要持久,才是正确的途径。
我认为在复杂软件系统种,业务逻辑的分析和认识需要排除任何技术细节,不断推入细化,这才是软件系统实现中最关键也是最难的。
|
櫴加载目前我知道有三种解决方式:
1. 2001年得Jive2.5中,在实体对象中设置一个boolean标致load是否执行。
2. Hibernate等框架使用动态代理,只有在使用访问时才通过动态代理load
3. 前面两种都符合DDD,这一种解决方式不是在实体内解决,而是外借服务等操作来进行,我在JiveJdon3中是这么做得。
不知你采取哪种,或者有更好得方式。
[该贴被banq于2007年07月08日 17:11修改过]