希望Model中增加putAttrs(Map attrs)这样的方法

菜根乱谭 发布于 2013/08/12 09:47
阅读 595
收藏 1

@JFinal 你好,想跟你请教个问题:

model中有两个setAttrs的方法特别方便,但是这个需要检查table字段,不是table字段是不允许set的。我现在有很多需求是这样的,我把一个大表拆成一些小表,处于效率考虑,但是返回到客户端,我希望将这些字段给放到一个对象中,调用setAttrs就报错了,因字段不符合要求。我希望能开放两个putAttrs方法,允许不检查表字段的情况下想attrs加入值。

加载中
0
JFinal
JFinal

    JFinal Model 提供了put 方法,当初是为了方便开发者在前端显示非数据库字段数据,从数据库查到List<YourModel>以后,可以先在后端循环对每个model put 点需要在前端显示的数据。

    如果考虑再加个put方法,那么肯定不能叫 putAttrs,因为attrs是属性,是与数据库字段对应的,只能考虑加个 putMap 或者什么别的

0
27号
27号
有不需要和table对应的put(String, Object)方法啊,不过你是想一次设置多个吧,这个还真没有。你可以自己继承扩展一下
菜根乱谭
菜根乱谭
这种需求如果多的话,还是在框架层来封装吧,自己再整一层只是为了做一些小的修改,代码不太好看
0
JFinal
JFinal

     CPI.getAttrs(Model model) 可以得到 Map attrs,然后 attrs.putAll(map)就可以了。JFinal目前的设计是为了尽可能避免开发者犯错,如果想打破规则也是可以的,用 CPI就可以。

    不过从 API 的一致性来说,既然有了  model.put(...) 那么添加一个 model.putMap(...)可以考虑

0
绝望的八皮
绝望的八皮

其实我不是太支持向model里面放非数据库字段,我觉得尽量去遵循语义,model就是一个table的映射。

一般有这样的需求我都用record.

0
黄开源中国
黄开源中国
最后落实到入库肯定是用model。。这样的话把无关的字段放进去model没意义,如果是相当vo来使用的话,那么record可以满足的
0
菜根乱谭
菜根乱谭

引用来自“绝望的八皮”的答案

其实我不是太支持向model里面放非数据库字段,我觉得尽量去遵循语义,model就是一个table的映射。

一般有这样的需求我都用record.

@绝望的八皮

我的观点正好和您相反,我认为record应该是数据表结果集的反应,而model应该是一个富血模型的领域模型,只不过这个领域模型是以表字段为核心的。

我现在的做法是将Model作为富血的POJO,它不仅仅承载着数据表的映射,它还承接着以业务对象为主业务逻辑,如果把所有的逻辑都放在controller中是不合适的,如果再搞出一层做服务,我们又回到了ssh时代,所以最好的方法就是用领域模型来承接服务。

打个比方:我有一个User的Model,可能我数据库有两三个表来体现User这个领域模型(比如user基本表,user资料表,user扩展表),我这个User的model可能就不是简单的映射user基本表那么简单了,因为它是一个领域模型,user领域的逻辑它要承接。对于user的服务封装我会在这个model中进行,对于三个表的操作,我可能都要在这个model中进行。

因为Model是ORM,是业务对象层面,而Db  Record这些才是真正的对应数据库的操作,我不喜欢打开Model类,里面除了声明dao,就没有任何东西了,如果仅仅是这样我们没必要搞什么Model,直接用Record就可以了,所以和您的观点正好相左。

@JFinal 您怎么看?

0
绝望的八皮
绝望的八皮

ar模式的一个含义是:

每一个数据库表对应创建一个类.类的每一个对象实例对应于数据库中表的一行记录; 通常表的每个字段在类中都有相应的Field

我是比较坚持这个原则的。避免语义被异化。

当然同时我也不是很学术的,觉得怎么好用就怎么来吧。

返回顶部
顶部