|
锁定老帖子 主题：一种传递分页参数的方法
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-03-02
ajoo 写道 如果是immutable的，当然返回一个新的dao对象了。这个对象和原来的旧dao对象肯定都共享很多资源的，基本上就是一个非常轻量级的decorator
这个“共享狠多资源”，是代码写出来的，还是JVM做的？ |
| 返回顶楼 | |
|
发表时间：2006-03-02
ajoo贴的java代码:
引用 interface UserService{
UserService withPagination(Pagination p);;
User findById(String id);;
User findByName(String name);;
......
}
interface UserDao{
UserDao withPagination(Pagination p);;
User findById(String id);;
User findByName(String name);;
...
} hongliang的回复 引用 ajoo，你这种方法，withPagination()方法返回的是什么？一个新的service/dao对象实例？本来service对象和dao对象可以是singleton的，按照你的这种方法，singleton可以吗？
拿spring举例来说： <bean id="daoDelegate" class="service.dao.hibernate.DefaultDAODelegate">
...
<bean id="abstractServiceTarget" abstract="true" class="service.AbstractService">
<property name="daoDelegate">
<ref bean="daoDelegate"/>
</property>
</bean>
<bean id="userService" parent="txProxyTemplate">
<property name="target">
<bean class="service.impl.UserServiceImpl" parent="abstractServiceTarget"/>
</property>
</bean>
(注：singleton缺省为true) 通过spring得到的userService并不是singleton的，因为声明的userService实际上是个ProxyFactoryBean，我猜想从spring中获取userService是这么一个过程（抱歉没深入看过源代码，凭感觉）： class BeanFactoryImpl{
Object getBean(String beanId);{
Object o = getBeanById(beanId);;
if( o instanceof ProxyFactoryBean);{
return ((ProxyFactoryBean);o);.createBean();;
}
return o;
}
}
ProxyFactoryBean {
Object createBean();{
//这里我理解应该每次都是新创建实例
Object o = enhanceOrProxyTarget(targetInterface, target);;
return (targetInterface);target;
}
void setTarget(Object o);;
Object getTarget();;
}
因此，配置中定义的userService和你在应用中获取的userService，不是同样一个东西。所以，虽然配置中userService(ProxyFactoryBean)是singleton的，但是应用中获取的userService只是ProxyFactoryBean的target的一个增强的实例而已。 不知道我理解对不对。 ajoo的答复 引用 如果是immutable的，当然返回一个新的dao对象了。这个对象和原来的旧dao对象肯定都共享很多资源的，基本上就是一个非常轻量级的decorator，所以singleton与否没有多大意义吧？节省那么几次创建对象的开销能省几个银子？
而如果是mutable的，就返回this。这样就可以singleton了。 mutable的优点，在于实现起来方便。缺点，在于状态会发生变化，如果用的不好，很可能出现不应该发生的分页之类的错误（比如，别的request做的分页影响到了当前request）。 我怎么感觉immutable(不变的)跟singleton(单实例)的关系更大一些？我有点糊涂了这里的immutable和mutable了。。。 |
| 返回顶楼 | |
|
发表时间：2006-03-03
举个简单的dao实现的例子
class MyDaoImpl implements MyDao{
private final Connection conn;
private final Session session;
....//all other dependencies
private final Pagination pagination;
public MyDaoImpl(Connection c, Session s, ..., Pagination pagination);{
this.conn = c;
this.session = s;
....
this.pagination = pagination;
}
public MyDaoImpl(Connection c, Session s, ...);{
this.(c, s, ..., null);;
}
public MyDao withPagination(Pagination newPagination);{
return new MyDaoImpl(conn, session, ..., newPagination);;
}
...
}
这个withPagination()基本上就是一个functional update，也就是说，生成一个新的MyDaoImpl，所有的field都原封不动照抄，只有这个pagination对象用传递进来的值。 这样，无论原始的MyDaoImpl是否singleton，这个withPagination()必然返回新实例。因为它就是一个轻量级的对象，所以不singleton也无所谓。 |
| 返回顶楼 | |
|
发表时间：2006-03-03
我受不了这个讨论叻，感觉越来越复杂，简单问题变复杂。。。我还是用老把式吧~~
|
| 返回顶楼 | |
|
发表时间：2006-03-15
sorphi 写道 public Pagination findPaginationByCriteria(final Class entity, final Pagination pagination); {
...
Integer count = (Integer); criteria.setProjection(Projections.rowCount(););.uniqueResult();;
if (null != count); {
...
记录数为0，就不继续查询了。。。 我觉得这个代码里面的count永远都不会为null。。。 Oracle里会为null uniqueResult()反正回的只是把数据库反回的值封装一下,具体有没有null值是要看数据库的,我现在只知道Oracle里count()的时候如果一条记录都没有会是一个null (抱歉,太菜了, ^_^) |
| 返回顶楼 | |
|
发表时间：2006-03-15
不知道是不是我理解错误。
因为ActionContext实际上是用ThreadLocal实现的。 直接在最终要处理的地方 Map params = ActionContext.getContext().getParameters(); 直接可以获取Parameters。 除了key解析比较麻烦之外，应该跟自己定义ThreadLocal没啥区别吧。 不仅仅Parameters， session 之类的也全在里面了。不用自己传了。 附 ActionContext的doc连接： http://www.opensymphony.com/webwork/api/com/opensymphony/xwork/ActionContext.html |
| 返回顶楼 | |
|
发表时间：2006-03-23
弱弱的问题一下，有的时候业务方法会对DAO区出来的数据进行筛选的，可能是那个安全框架的需要，这个时候只接在DAO里面分页会不会变得很奇怪？？？
|
| 返回顶楼 | |
|
发表时间：2006-03-23
我有一个想法，在dao/service层，不带分页的参数，但是也不实际查询，只是暗中生成sql,到了Action层，加上分页的条件后，getResult的时候才真正去查询。
这样效率和接口的美观都照顾了。 不知道有没有人知道我的意思? |
| 返回顶楼 | |
|
发表时间：2006-03-24
这个实现起来好像有点困难。
|
| 返回顶楼 | |
