JdonFramework 6.0发布

使用Jdon框架6.0开发应用将变得异常简单，甚至无需XML配置文件，只需要两步：
第一步：将存在依赖关联关系的两个类用@Service或@Component(两者性质一致)标注：

@Service("helloService")
public class HelloServiceImpl implements HelloService
..

@Component
public class UserRepositoryInMEM implements UserRepository {


第二步：客户端调用代码:
HelloService helloService = (HelloService) WebAppUtil.getService("helloService", req);
String result = helloService.hello(myname);

无需jdonframework.xml配置文件和相关XML配置。DI依赖注射原理图见下：
全部演示代码见JdonFramework源码包目录下examples/testWeb

至此，Jdon框架业务层应用基本全部实现Annotation注解，Annotation做到少而精：

@Poolable 表示当前类的实例是从对象池中获得。
@Stateful 表示当前类的实例是与用户状态相关的。
@Singleton 表示当前类的实例是单例。
如果没有以上注解，缺省当前类的实例相当于new，每次请求一次。
以上几种类的创建模式在性能上，对于代码小的类差别都不大，已经经过测试。响应在70毫秒左右。

@Model 是用来对领域模型进行注解。


下载页面：
http://www.jdon.com/jdonframework/download.html


[该贴被admin于2009-07-20 17:41修改过]


jdonframework 6.0具体变动如下：
（一）增加Annotation注射功能， @Service或@Component替代了原来XML配置:
<pojoService name="给自己类取的名称" class="完整类的名称"/>
或者在具体类代码上加入：@Service("给自己类取的名称")

<component name="给自己类取的名称" class="完整类的名称"/>
或者在具体类代码上加入@Component("给自己类取的名称")

Service和Component都表示组件构建概念，可以是一个类，也可以是一个类为主的多个类，如果这个组件供客户端调用，那么就称为服务。两者在Jdon框架中没有区别，只是使用时称呼不同而已。
@Component(“给自己类取的名称”)也可以简化为@Component，这样，Component的名称就是该类的完整类名称(getClass,getName())；
@Service则不可以这样，因为是供Jdon框架容器以外的外部客户端调用的，一定要取一个名称。
因为需要被客户端调用，那么就要指定服务的名称，所以，@Service与@Component的区别就是，@Service必须规定一个名称@Service("给自己类取的名称")；而@Component则没有name属性，缺省是类名称getClass().getName()名称，如果客户端有时需要临时直接调用@Component标注的组件，也可以按类名称调用。


（二）.增加@Singleton Annotation，缺省客户端调用getService时，每次请求获得一个新的Service实例，也可以使用@Poolable对象池来对代码比较大的Service类进行性能提高，现在又提供了另外一种方法，使用单例@Singleton。
单例和对象池区别主要是：对象池可以进行实例最多个数控制，这样，能够保护服务器不会被尖峰冲击造成资源耗尽。
在Service服务代码比较简单小的情况下，Service实例三个创建方式：单例、对象池以及每次请求生成一个新实例，在性能上几乎没有太大差别，已经使用框架源码包中examples目录下的testWeb经过测试了。


（三）.没有将有关Action的配置转为Annotation，原来的配置如下继续保留：
<model key="username"
class="com.jdon.jivejdon.model.Account">
<actionForm name="accountForm"/>
<handler>
<service ref="accountService">
<initMethod name="initAccount"/>
<getMethod name="getAccountByName"/>
<createMethod name="createAccount"/>
<updateMethod name="updateAccount"/>
<deleteMethod name="deleteAccount"/>
</service>
</handler>
</model>
因为这个配置是有关MVC表现层，而表现层不是Jdon框架的核心，所以，Jdon框架核心是业务层，对Domain Model和Service服务组件进行管理，所以，不能在业务层耦合具体表现层。上述配置可以认为是表现层和业务层的桥连接配置。

恭喜Jdon6.0发布！！！

关于Component和Service定义：
这个定义是从业务领域来定义的。
无论是Evans DDD、NGOSS或者SOA，他们相同定义是：

组件(构件) Component:
1.功能的实现。
2.供第三方使用组合的入口
3.可管理的单元

服务Service：
组件的集合

无论组件和服务，都不是真正将业务功能在自身实现，而是委托，委托给谁？委托给Domain Model领域模型，用NGOSS术语：就是委托给合约Contract，而Contract是用于规定相互调用实体之间信息和功能是如何交互的。

所以，别以为Jdon框架是在屋子里闷头做出来的个人作品(home-grown)，而是综合很多业务设计理念Evans DDD NGOSS和SOA基础的。（大白话：当然比纯SOA更厉害了）

SCA更多是一个市场产物:SCA容器没有IOC containers更加直接了当
http://www.jdon.com/jivejdon/thread/36650.html
[该贴被admin于2009-07-29 11:56修改过]

这个Component怎么跑起来？


@Component
public class InFilterManager {	
	private Collection inFilters;

	public InFilterManager(String[] inFilterClassNames) {
		initFilters(inFilterClassNames);
	}

	private void initFilters(String[] filters) {
		try {
			inFilters = new ArrayList();
			for (int i = 0; i < filters.length; i++) {
				String className = filters[i];
				inFilters.add((MessageRendering) Class.forName(className).newInstance());
			}
		} catch (InstantiationException e) {
			throw new ForumException(e);
		} catch (IllegalAccessException e) {
			throw new ForumException(e);
		} catch (ClassNotFoundException e) {
			throw new ForumException(e);
		}

	}
}

[该贴被oojdon于2009-07-22 16:33修改过]

需要常数配置的Component没有支持，还是需要XML配置，这正好发挥XML配置的作用，XML用来作为配置，一些常数字符串的配置修改，而且修改后，无需重新编译软件，即可运行。

哇,jdonframe愈来愈简单,太好了.顶个!
BANQ老师,持久层daoCRUD和hibernate的注入还要自己配置吗?

>持久层daoCRUD和Hibernate的注入还要自己配置吗
多谢，应该不用配置，如果你实现或继承DaoCRUDTemplate以后，在这个继承子类上标注@Componnet就可以。
但是，如果直接使用框架中的组件，还是需要XML配置，这个方面方便性，这个版本还没有考虑到，我先思考一下如何协调，如果你有好的建议，也提出来，谢谢。

关于为什么不增加@Transaction支持注解的说明：

使用Jdon框架可以使用事务机制，在代码中直接写JTA调用就可以(可见JiveJdon源码)，那为什么Jdon框架不直接@Transaction注解呢？

主要是设计理念不同：我个人一直认为：事务是软件不可伸缩的罪魁祸首，给一段代码标记上事务，实际表明，这段代码中方法操作就是串行化的。我们可以使用基于内存对象模型的并发锁来替代事务操作，事务最后就异化为专为数据库操作准备的技术。

既然是为数据库等资源准备的技术，为什么要上升到业务层呢？业务层完全可以基于缓存中领域模型对象的并发锁机制来实现，更有甚者，可以采取云计算框架来帮助实现。实现方式见：http://www.jdon.com/jivejdon/thread/36633.html

所以，事务在某种程度上代表串行化计算，和云计算 异步处理 并行计算等概念是矛盾的。我们必须为降低事务粒度而和业务进行某种博弈，这时框架不能在其中再偏向事务串行化阵营。而EJB框架，以及整合Hibernate后的Spring框架，业务层缺省是事务的，是偏向事务阵营的。
见这个讨论: http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=36063&message=23122681#23122681

以及：
http://www.jdon.com/jivejdon/thread/36633.html
[该贴被admin于2009-07-25 17:49修改过]

谢谢banq老师的回复！刚更新到6.0，正在使用中

找不到 aopalliance.jar 这个包
是不需要么