2005新年献礼：JdonFramework开源项目正式推出！
http://www.jdon.com/jdonframework/
http://www.jdon.com/jdonframework/
我大概看了一下介绍，有两个疑问。第一，UserTest类继承Model类，请问这个约束是否必须的？第二，既然client直接打交道的是一层POJO，为什么下面的业务逻辑要用EJB来实现？请解答一下这两个问题。
JdonFramework明显优点是：性能的成熟性，例如缓存无所不在，这是区别一些概念性开源项目的明显特征，使用JdonFramework开发，开发者无需关注太多性能缓存问题。
回答两个问题：
1.目前UserTest这样模型对象需要有约束，但是我们已经从pico和JMX的结合中发现，可以实现去除这种约束。
2. client一个请求可以只到POJO结束（如果你使用POJO做Business Object），所以该框架是横跨EJB/POJO两种架构的，你可以先使用POJO实现你的业务核心，以后在使用EJB实现，只要配置一下，这和Spring是相同的。
可以说，JdonFramework是介于Spring和AppFuse、JPetStore之间，试图寻找一个中间点，当然还有更大的区别，是对EJB支持和优化。
请问什么是Model？我看到的是UserTest extends Model，那么这个继承关系能够提供什么？为什么这些feature是POJO不能提供的？
>>JdonFramework明显优点是：性能的成熟性，例如缓存无所不在
我确实看到了缓存无所不在：clearCache()这样的代码不断地在业务代码中重复。在你的介绍中声称，cache问题是以AOP的方式解决的，那么AOP在哪里？为什么clearCache()还在不断地侵入业务代码？
>>这是区别一些概念性开源项目的明显特征，使用JdonFramework开发，开发者无需关注太多性能缓存问题。
我的判断恰恰相反。如果采用Spring来架构应用（例如AppFuse和JPetStore都是这样），cache问题是真正以AOP的手段解决的，因此开发业务逻辑时完全可以不考虑cache，到真正需要的时候再做一个专门处理cache的aspect，把它weave in就可以了。而在JdonFramework这里，我看到的是：开发者必须常常想着――至少是――clearCache，难道这叫“无需太多关注性能缓存问题”吗？
一个非常简单的问题。A，业务逻辑完全不关心任何cache相关的事，需要cache的时候可以动态weave in一个cache aspect，需要修改缓存策略只需要修改这一个aspect。B，业务逻辑中到处出现clearCache()这样的调用，一旦修改缓存策略就必须改二十八个业务类。我请问，究竟哪一个方案对开发者更有利？哪一个方案是强制让开发者不断关注缓存问题？
com.jdon.servicelocator.ejb.ServiceLocator没有，不明白。
http://www.theserverside.com/news/thread.tss?thread_id=30797
我看有些问题我们还是关起门来讨论清楚了比较好。大的架构我都暂且不谈，就说这个缓存的问题，如果回头让hani看到一个声称有AOP的应用里到处都是clearCache()，呵呵，恐怕到时候你只会希望自己看不懂英文。所以，在hani和rickard关注到你的框架之前，也许你最好能先把我说服了，毕竟我在国内搞AOP的时间相对长一点。
我希望我们国内能有更多优秀的开源项目和老外一起并列，我就是我开源JdonFramework的目的所在。
JdonFramework只是使用AOP的小部分，因为它不是一个为客户服务的AOP框架，而是为框架内组件服务的，如果你需要为你服务的AOP框架，使用Spring.Jboss AOP就可以。
JdonFramework试图在走一个新的方向，而不是重复.
OK，第一个问题解决了。第二个问题跟Pieter Van Gorp问的有关，也是我昨天问了但没有得到回答的。UserTest extends Model，Model类是什么？它提供什么？为什么它提供的东西是POJO不能提供的？
请举例说明。你应该知道，对我说“这里只有深入到此处的人才会有感悟”这种话是没有意义的。现在请试举一例：必须在业务代码中嵌入clearCache()之类代码才能解决缓存问题。谢谢。