|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-12-15
nihongye 写道 引用 Over the past 20 years I have actually moved away from the view represented by the idea of telling domain objects to persist themselves. Fowler may say my domain objects are anemic, but they are easy to maintain and keep in synch with various forms of persistence such as databases (relational, object, etc.) and messages. I have found that letting to service or business object act as a controller between the domain object and the interface (or view) object, the DAO, is the best way to go. MVC really represents a meta pattern of object specialization where all objects are either controllers, interfaces or domain objects but never a combination. Mediators, adaptors, connectors, MVC itself and other design patterns all work in this way. I've found that it makes the objects simpler, easier to maintain and more reusable. What is being suggested here is similar to injecting Strings with formatting objects and then telling them to go format themselves. It sounds nice, except it gunks up String. Why should the author of String have to plan for formatting or any other arbitrary operation that someone may have in mind for Strings? Why should domain object authors concern themselves with a specific DAO interface? There is no DAO interface standard. People can define their own. Do I clutter my domain object with code for each possibility? Domain objects, if done correctly can be used across applications across the enterprise. Objects should know all about themselves and as little else as they can get away with.
看了这个发言想到: 考虑Domain Logic需要扩展的情况: 结果User就想出个办法,弄出一个UserLogicProxyInterface. 在这里是否有UserLogicProxyInterface.其它的领域对象并不知道,是User自己想的一个办法. 而考虑贫血模型: UserLogicService不就相当于UserLogicProxyInterface嘛.但问题是 贫血模型把一个本来是一个User自己的勾当的方法上升到整个系统. 如果需要在User上构造一个UserLogicProxyInterface,多半是请求者对他提出的。 怎么会是User自己想的呢？ |
| 返回顶楼 | |
|
发表时间：2005-12-15
请求者对User提出的是各种各样的需求.User提供UserLogicProxyInterface作为逻辑的可扩展点来应付各种各样的需求.
|
| 返回顶楼 | |
|
发表时间：2005-12-15
nihongye 写道 ajoo提供的是完全的对domain object DI的方案.
使用annotation觉得怪，弄几个字符串出来叫annotation，然后就跟一堆object搞在一起，怪怪的解决方案 可以试试postLoad callBack. 赫赫，这会很不错，也不用走那么多弯路了。  
|
| 返回顶楼 | |
|
发表时间：2005-12-16
aspectj当然也不一定就必须用annotation。后来Adrian写的文章就给出了另外一种不用annotation的方法。当然，也没什么希奇的，不过是个marker interface而已。
http://www-128.ibm.com/developerworks/java/library/j-aopwork13.html 这个方法的问题在于，对应每个domain object类型，如Bank, Account, Person，都要单独写一个aspect。 这很烦琐。 不知道aspectj支持不支持动态pointcut。如果pointcut可以从spring注入到aspect里面，我们就可以让spring配置pointcut，这样一个通用的aspect就可以搞定一切。 public aspect GeneralInjector {
private Injector injector;
private Pointcut clientcut;
public void setInjector(Injector injector);{
this.injector = injector;
}
public void setPointcut(Pointcut clientcut);{
this.clientcut= clientcut;
}
after(Object aClient); returning :
clientcut(aClient); {
injector.inject(aClient);;
}
}
<bean id="accountinjector" .../>
<bean name="accountAspect"
class="org.aspectprogrammer.dw.GeneralInjector"
factory-method="aspectOf">
<property name="injector">
<ref bean="accountinjector"/>
</property>
<property name="pointcut">
initialization(AccountOperationValidationClient+.new(..););
</property>
</bean>
|
| 返回顶楼 | |
|
发表时间：2005-12-16
不知ajoo的动态pointcut是什么效果。
静态方式似乎也能满足需求。 |
| 返回顶楼 | |
|
发表时间：2005-12-16
其实,我并不在乎动态与否.
我是希望能够在配置文件里面配置这个point cut。因为给谁注射决定了怎么注射。这两者是紧密相关的。 Adrian的那个文章里，他把pointcut这个“给谁注射”静态编码在aspect里，而把“怎么注射”放在配置文件里，造成了每个domain class一个aspect的局面，无法重用aspect。 |
| 返回顶楼 | |
|
发表时间：2005-12-24
原来xml配置也可以很轻松的：
http://www.iteye.com/pages/viewpage.action?pageId=641 |
| 返回顶楼 | |
