充血模型探讨

大东哥 发布于 2010/08/10 17:15
阅读 1K+
收藏 3

这个话题在je上没讨论出什么,就被隐藏了,还是想放在这里继续讨论。

用java来实现领域建模,体验不好,比较痛苦,限制太多。
用动态语言,ruby,groovy等来实现领域建模,体验很棒,实现起来也很自然。
如grails下简单的下订单例子:
//用户
class User {
   String username
   String password
   
   //我的订单
   def myOrders(){
     Order.findAllByUser(this)
   }
  
   //购买

   def buy(){
      new Order(user:this).save()
   }

}


//订单
class Order{
   User user
}

controller中调用方式:

def loginUser = User.get(session.userid)
def orders = loginUser.myOrders()

loginUser.buy()

各位o友觉得这样的模式会有什么问题吗?有人说,这是面向过程式的充血模型,有人说,这种方式很不好维护,不好扩展,吧啦吧啦的。。 我到觉得这方式很直接,自然。欢迎o友讨论,有思维的碰撞才有灵感,在思想的碰撞中各自感悟,进步。

加载中
0
爆皮王
爆皮王

放到实体里面去操作的话 的确是可以省一些判断  但不能什么都放到里面  那样的话  里面的会变得很庞大

0
大东哥
大东哥

什么可以放到里面?什么不该放到里面?

0
红薯
红薯

oschina 就是将业务逻辑直接放在实体对象中,有些实体类的确比较庞大,大部分还好。

0
大东哥
大东哥

红薯老大抛弃了传统的三层贫血模型的开发方式,看oschina的表现,效果很好啊。

我也认为像这模型,buy动作,自然给user,只有user最了解自己的状态,如积分,余额,打折卡信息,在实际项目的buy动作中,就需要这些信息。

0
红薯
红薯

引用来自#5楼“东明”的帖子

红薯老大抛弃了传统的三层贫血模型的开发方式,看oschina的表现,效果很好啊。

我也认为像这模型,buy动作,自然给user,只有user最了解自己的状态,如积分,余额,打折卡信息,在实际项目的buy动作中,就需要这些信息。

是,我也是这样认为的,例如 topic.delete() 直接就是删除实体类,很好理解。

但的确有些类很大,维护起来也着实费劲,目前也没什么好想法,先这么着吧

0
rockjava
rockjava

引用来自#4楼“红薯”的帖子

oschina 就是将业务逻辑直接放在实体对象中,有些实体类的确比较庞大,大部分还好。

老大,能否把oschina充血模型结合代码列出一些来,学习学习。

0
Yongqiang
Yongqiang

如果逻辑是围绕当前类的,当然是放到类的内部,比如User的Buy,但如果逻辑要涉及多个Domain类,像MyOrder这种情况,最好放到其他类里,比如某个Service,不然耦合太高了。

0
爆皮王
爆皮王

引用来自#8楼“Yongqiang”的帖子

如果逻辑是围绕当前类的,当然是放到类的内部,比如User的Buy,但如果逻辑要涉及多个Domain类,像MyOrder这种情况,最好放到其他类里,比如某个Service,不然耦合太高了。

嗯,我也觉得是。

0
大东哥
大东哥

引用来自#9楼“爆皮王”的帖子

引用来自#8楼“Yongqiang”的帖子

如果逻辑是围绕当前类的,当然是放到类的内部,比如User的Buy,但如果逻辑要涉及多个Domain类,像MyOrder这种情况,最好放到其他类里,比如某个Service,不然耦合太高了。

嗯,我也觉得是。

像myOrder这样的逻辑,我倒认为更应该放到user中,这样一来,不会误操作吧属于其他用户的order拿出来,还可以在里面判断是否属于本用户,如

def myOrder(id){

   def order = Order.get(id)

if(order.user == this)

return order

else

return null

}

一句话,user最了解自己。

0
红薯
红薯

引用来自#10楼“东明”的帖子

引用来自#9楼“爆皮王”的帖子

引用来自#8楼“Yongqiang”的帖子

如果逻辑是围绕当前类的,当然是放到类的内部,比如User的Buy,但如果逻辑要涉及多个Domain类,像MyOrder这种情况,最好放到其他类里,比如某个Service,不然耦合太高了。

嗯,我也觉得是。

像myOrder这样的逻辑,我倒认为更应该放到user中,这样一来,不会误操作吧属于其他用户的order拿出来,还可以在里面判断是否属于本用户,如

def myOrder(id){

   def order = Order.get(id)

if(order.user == this)

return order

else

return null

}

一句话,user最了解自己。

支持,但 OSChina 的 User 类已经有将近 1000 行了,而且增长也比较快,头大。

返回顶部
顶部