|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-06-14
agapple 写道 合并多次的get/set请求生成字节码调用(你可以理解为动态编译成类的属性调用) 我只能说 你的描述。。。比较难懂。。。 
|
| 返回顶楼 | |
|
发表时间：2011-06-14
最后修改：2011-06-14
Reset 写道 agapple 写道 合并多次的get/set请求生成字节码调用(你可以理解为动态编译成类的属性调用) 我只能说 你的描述。。。比较难懂。。。 你就这么理解把，比如说我有100个属性要进行mapping。我可以是每次进行一个属性处理(每次都经过方法反射调用)，也可以是一次性取出100个属性的值进行处理，会有一些细微的性能上的差别(可以提升几倍把) 你提的动态编译成类，你理解就是一个batch处理过程的一种方式，调用编译生成的类，批量的调用get方法。 这也是一些常见的优化处理，你看spymemcached,xmemcached都有类似的batch处理 |
| 返回顶楼 | |
|
发表时间：2011-06-14
agapple 写道 Reset 写道 agapple 写道 合并多次的get/set请求生成字节码调用(你可以理解为动态编译成类的属性调用) 我只能说 你的描述。。。比较难懂。。。 你就这么理解把，比如说我有100个属性要进行mapping。我可以是每次进行一个属性处理(每次都经过方法反射调用)，也可以是一次性取出100个属性的值进行处理，会有一些细微的性能上的差别(可以提升几倍把) 你提的动态编译成类，你理解就是一个batch处理过程的一种方式，调用编译生成的类，批量的调用get方法。 这也是一些常见的优化处理，你看spymemcached,xmemcached都有类似的batch处理 你的解释让我有点糊嘟 你说的字节码调用 是指反射么后还是 class(字节码) ? |
| 返回顶楼 | |
|
发表时间：2011-06-14
Reset 写道 agapple 写道 Reset 写道 agapple 写道 合并多次的get/set请求生成字节码调用(你可以理解为动态编译成类的属性调用) 我只能说 你的描述。。。比较难懂。。。 你就这么理解把，比如说我有100个属性要进行mapping。我可以是每次进行一个属性处理(每次都经过方法反射调用)，也可以是一次性取出100个属性的值进行处理，会有一些细微的性能上的差别(可以提升几倍把) 你提的动态编译成类，你理解就是一个batch处理过程的一种方式，调用编译生成的类，批量的调用get方法。 这也是一些常见的优化处理，你看spymemcached,xmemcached都有类似的batch处理 你的解释让我有点糊嘟 你说的字节码调用 是指反射么后还是 class(字节码) ? 字节码调用是通过生成bytecode，你理解就是动态生成了一段已经编译了的代码。比如一段invokevirtual xxxMethod的代码。 正常的beanutils都是使用Method.invoke反射调用，jdk1.6之后反射调用的性能优化的已经很不错。
|
| 返回顶楼 | |
|
发表时间：2011-06-14
使劲看了两遍，还是没看明白真正的应用场景，如果是定位于跟名字那样，bean mapping/conversion，本也是无可厚非的，但一开始那段提到了hibernate，以为是一个更猛的替代品——然而不是，对吧？
LZ看看是不是可以理解主要用于这些应用场景： 1、常见于MVC框架的form<->bean conversion？ 2、基于pulling的Business Domain -> DAO持久化对象“自动”映射转换？（这个有点拗口，即访问业务模型，但业务模型跟DAO模型可以不一样，但可以自行trigger+转换？） 如果仅仅是bean的复制/转换+性能提升，就不要用这么多XML了吧，顶多用些简单的annotation——毕竟你也用JDK1.5以上了 |
| 返回顶楼 | |
|
发表时间：2011-06-14
itstarting 写道 使劲看了两遍，还是没看明白真正的应用场景，如果是定位于跟名字那样，bean mapping/conversion，本也是无可厚非的，但一开始那段提到了hibernate，以为是一个更猛的替代品——然而不是，对吧？
LZ看看是不是可以理解主要用于这些应用场景： 1、常见于MVC框架的form<->bean conversion？ 2、基于pulling的Business Domain -> DAO持久化对象“自动”映射转换？（这个有点拗口，即访问业务模型，但业务模型跟DAO模型可以不一样，但可以自行trigger+转换？） 如果仅仅是bean的复制/转换+性能提升，就不要用这么多XML了吧，顶多用些简单的annotation——毕竟你也用JDK1.5以上了 其实你的annotation也是一种配置，只不过展示显示不同而已。 两种配置的选择，也是仁者见仁，智者见智的问题了。没必要太过于纠结 你描述的两个业务场景，基本上也就是我们现在遇到比较多的。只不过我们现在大范围进行重构，构建SOA服务时，第2个场景的问题就特别明显 引用 但一开始那段提到了hibernate，以为是一个更猛的替代品——然而不是，对吧？
哈哈，这个只是一个引子 |
| 返回顶楼 | |
|
发表时间：2011-06-14
个人感觉挺好的，找个时间好好拜读下。
|
| 返回顶楼 | |
|
发表时间：2011-06-14
agapple 写道 bugu1986 写道 agapple 写道 当然支持，只不过你得告诉我这是一个需要做深度复制的对象。默认只做第一层复制
你们淘宝带代码出来看起来还是蛮开放的。。。不像我们，不管涉不涉及业务，是代码就带不出来。。。 确实插件化的设计还是很赞的，另外用script在xml里面，我们的项目里也有用，感觉表达能力很强，很好。 从哪里看出有淘宝的信息？ 呵呵，我非淘宝人员 可以这么说，代码是你自己写的。只不过用在公司的某个项目上而已 我们一般也会要求，涉及公司信息的代码或者信息不能在blog里讨论 来自杭州。。我经验主义了。。呵呵 |
| 返回顶楼 | |
|
发表时间：2011-06-15
agapple 写道 你描述的两个业务场景，基本上也就是我们现在遇到比较多的。只不过我们现在大范围进行重构，构建SOA服务时，第2个场景的问题就特别明显 OK，扯上了SOA，那就应该考虑叫做xmlbeanMapping更有用武之地，跟XMLBeans之流的对着干 有时候我倒是怀念起ETL |
| 返回顶楼 | |
|
发表时间：2011-06-15
itstarting 写道 agapple 写道 你描述的两个业务场景，基本上也就是我们现在遇到比较多的。只不过我们现在大范围进行重构，构建SOA服务时，第2个场景的问题就特别明显 OK，扯上了SOA，那就应该考虑叫做xmlbeanMapping更有用武之地，跟XMLBeans之流的对着干 有时候我倒是怀念起ETL 呵呵，兄弟，别这么较真么。 就和你用spring一样，虽然它大部分也是用xml配置，同样你也可以使用api方式和annotation，这个是每个开发者自己的选择。 xml只是目前的一种配置方式，后续是马上有计划实施api，annotation的配置。 |
| 返回顶楼 | |
