请教关于domain对象注入service

其实lz讲到了一个 domain和 service如何切分的问题？
Service业务逻辑与Domain业务逻辑切分的原则
两种原则:
1. 领域模型只包含了不依赖于持久化的领域逻辑，而那些依赖持久化的领域逻辑被分离到Service层。
2. 使用Rod Johnson的”case by case”原则。可重用度高的，和domain object状态密切关联的放在domain中，可重用度低的，和domain object状态没有密切关联的放在Service中。

http://cavingdeep.cnblogs.com/archive/2004/10/28/208956.html

domain 当作是个体行为。。。

service 当作是群体行为。。。。

这么区分就可以了

虽然大家有点烦EJB，但他里面的entity（特别是ejb3以后），和session的关系和你讲的关系有点相似哦。
实体和操作分开也是sun的选择。

说的不对的，荒淫大家拍砖

可以这样，但是软件分层就不明显了吧，你理解了并不代表团队其他人能理解。而且这样我觉得也不是很通用。可能会造成很多重复代码。重构性不是很好。

我的做法是：
1.domain中只定义属性，getter,setter，所谓贫血模型。
2.在service层注入dao,对数据进行操作。
3.struts2+spring可以把action作为service层，只要自己继承一个继承自ActionSupport的父类，以后容易移植。
4.使用spring+hibernate可以写一个公共类，实现dao层是一个只有一个类的层。

你说的domain是什么

我觉得我同意这个说法
带持久化的逻辑还是不要放在domain object里的好

前几天遇到一个问题.
需要把cookie的user用户的一些属性传到dao中去.
中间service一点没用上.
改了三个类之后恶心的厉害......
测试又没办法测,
传过去又没什么大用.
不如把内容放在用户中
把用户传到后台去
想想还是不能免俗

还真是没有dmain没办法
圆满完成这种杂技动作

还是就楼主的疑问。我感觉自己之前的回复有些片面了。
面向对象不仅仅单纯的是：某个对象有哪些属性和行为，把这些属性和行为封装到一个类里——认为这就是面向对象了。
一个程序是否是面向对象的设计，还需要考查它是否符合：单一职责原则、开放封闭原则、依赖倒置原则等设计原则。
这说开了就太大了，我就捣一下乱吧。