search

lishunli / nutz

Automatically exported from code.google.com/p/nutz
0 stars 0 forks source link

MVC默认适配器问题 #177

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 

1. 
使用@Param("..")对对象进行注入,因为在ObjectPairInjector.GET中是直
接使用
injs进行注入的,而在构造函数中生成的子类是:InjectBySetter
2. 
在ObjectPairInjector.GET中是直接递归names,然后对每个name都request��
�面查
询,如果有,则注入,但是如果不存在呢?同样会调用对应injs的进
行注入.这样问题就来
了.
3. 
如果我的实体中某个属性并没有get/set方法呢?这样就不能注入
了.就会抛异常

直接给出我的解决方案吧,看那们做下修改
ObjectPairInjector.java:

Injecting inj = injs[i];
String s = req.getParameter(names[i]);
inj.inject(obj, s);

Injecting inj = injs[i];
if(req.getParameterMap().containsKey(names[i])){
    String s = req.getParameter(names[i]);
    inj.inject(obj, s);
}

我这里只是简单的做了一个判断,其实我还有种想法,为什么这
里是根据实体内所有的
属性来判断注入呢?为什么不是服务类对实体进行探测再注入�
��?

Original issue reported on code.google.com by zkgale@gmail.com on 9 May 2010 at 9:56

GoogleCodeExporter commented 9 years ago 
1. 还有可能是 InjectByField ， 请参看 Mirror.getInjecting 函数
2. 说的对，做了修正 r1205， 
如果没有将跳过，如果为空串，注入 NULL 
3. 通过 InjectByField， 没有 getter/setter 依然可以被正确注入

最后一段话，没有明白你的意思， 什么叫 “服务类” ， 
什么叫 “探测” ？

Original comment by zozoh...@gmail.com on 10 May 2010 at 2:52

GoogleCodeExporter commented 9 years ago 
恩,我最近才使用NUTZ做个小东西,也没怎么看源码,基本上都是�
��问题的时候才看看,但是,虽然只
看了一点,但是感觉在注入方式上有些地方不是很舒服,就拿这
个问题所在的地方来说吧,这里所选
择的方式是这样的形式:
1. 获取方法参数的对象
2. 递归得到对象的属性
3. 
使用这个属性在request里面去探测,寻找,是否有合适的值,如果�
��注入,没有则放弃

也不是说这种方式不好,我只是觉得这种形式有些弊端,比如:
1. 
如果我有多个对象呢?而且多个对象都同时有同一个属性名呢?
2. 
如果我没有属性,只有一个setXXX()方法呢?这个setXXX()方法同样��
�我要注入的,那怎么办?
(比如通过setXXX()传一个值进行计算后分别赋值给多个属性)
3. 
而且从职责的角度来看,接受注入的对象成了主导,也就是说,��
�象有些什么,它就可以去抢点什
么过来...感觉有点别扭.

现在我们再回到我说的最后一句话,为什么我们不通过外部探�
��的形式呢?
比如,我有这样一个请求:
find.htm?user.name=张三&user.father.name=李四&user.father.father.name=王五
那么我们是否可以先去找有没有user这个对象,然后探测(猜测)u
ser这个对象里面是否可以注入
father这个属性,这里注入的形式可以是属性注入,set注入等,无��
�谓,只是探测有没得,如果
有,OK,给你,没得,我不管你,这样的话,就与现在注入的形式完全
反转了,不再是我差什么你就得给
我什么,而是你有什么,你能给我什么.
另外,上在的那个URL是struts2里面的一种形式...

Original comment by zkgale@gmail.com on 11 May 2010 at 6:50

GoogleCodeExporter commented 9 years ago 
关于 
find.htm?user.name=张三&user.father.name=李四&user.father.father.name=王五
的这种需求，可以参看 Issue 72
通过 @Param("::user") User user 来声明参数即可

至于特性：一个对象，需要通过 setter 
注入，这个对象本身并没有这个属性。
在实际的项目里，不是必须的，但是如果我们能找到一个真��
�的例子来说明，这个特性是必要的，不要不行，我们会考
虑加上

关于解析方式， 是依靠实体对象.fields还是依靠 request.name 
来遍历，由于考虑到可能 
request.getName 可能效率比较高
以及，我可以预先判断一个对象的字段是要调用 setter 还是 
field，也就想当然的用泪 对象.fields 来遍历。
其实我觉得两者的速度可能没什么太大差别，只是我们现在��
�没有一个严格的性能测试来证明哪种方法更好

Original comment by zozoh...@gmail.com on 11 May 2010 at 7:48

GoogleCodeExporter commented 9 years ago 
如果你想通过 Request 传入一个 user.father.father.name 
之类层级很多的对象，我觉得用名值对是不方便
的，应该用 Json

Nutz 也提供了 JsonAdaptor

Original comment by zozoh...@gmail.com on 11 May 2010 at 7:49

GoogleCodeExporter commented 9 years ago 
恩,继续深入关注的,谢谢你对我这些想法的解答.

但是JsonAdaptor有个麻烦的地方是要手工去组装表单...这个要是
表单多的话有点烦

另外,关于性能的考虑,<重构>里面一直在强调别把性能做为参�
��依据,只有结构好的情况下再去调整
性能才是好的...

Original comment by zkgale@gmail.com on 11 May 2010 at 7:57

GoogleCodeExporter commented 9 years ago 
通过 jQuery 等扩展库，很容易组装出一个 JSON 对象吧 .....

Original comment by zozoh...@gmail.com on 13 May 2010 at 7:08

GoogleCodeExporter commented 9 years ago

Original comment by wendal1985@gmail.com on 13 May 2010 at 11:00

GoogleCodeExporter commented 9 years ago 
Reopen by 天行健's case below

Original comment by zozoh...@gmail.com on 21 May 2010 at 7:57

GoogleCodeExporter commented 9 years ago 
如果我使用混淆工具将我的代码混淆了，即使字段名字相同��
�没法注入，因此建议Nutz的实现尽量遵循
JavaBean规范。以保证用户能在代码改动最少的情况下平移到Nut
z框架中。

Original comment by jiongs...@gmail.com on 21 May 2010 at 8:02

GoogleCodeExporter commented 9 years ago 
上一个
Comment 9 by jiongs753, May 21, 2010
由issue 203 管理.

Original comment by wendal1985@gmail.com on 4 Jun 2010 at 2:47