三层中数据返回的问题?(谢绝灌水,提前有分) (200分)

  • 主题发起人 主题发起人 only you
  • 开始时间 开始时间
O

only you

Unregistered / Unconfirmed
GUEST, unregistred user!
请问我有一个检索多表并返回数据集的问题,可能返回很多数据,
那在中间层上如何构造这个商业逻辑,就是说用类如何将它表示
出来并正确的返回到客户端。请说的详细点,但不必到代码级别
 
把商业逻辑变成函数供客户端调用。
 
具体谈一下构架,另外请注意我的要求,符合要求的给全分,不会给灌水的分数,泛泛而谈就是
灌水
 
返回数据集是多行的情况下,而且数量还不确定,采用CORBA结构,我在
应用服务器上的对象中如何表示出来哪?
 
你可以传_Recordset智能指针
也可以用TDatasetProvider和DComConnection
具体就是李维的<<分布式数据库开发篇>>
 
可惜的是我想用java开发,要不为什么发在JAVA版哪?
 
给你一份文档,可以参考一下,对于当量数据的现实问题,目前我也正在寻找一个比较好的办法,
如果使用远程调用的话,代价太昂贵了,使用存储过程可能会好一些。但是不利于扩展,尤其当
我们进行大型项目的开发的时候,后期维护消耗太大,可以考虑使用DAO直接访问,然后从数据库
直接返回数据,存放在容器中,而不要采用产生一个新的DATA OBJECT,调用SET和GET方法进行数据的
存放以及处理(这样耗费的时间不亚于从数据库中取出大量的数据,并且加重了垃圾回收器的负担)。
http://www.cn-java.com/download/data/book/petstoreModel.pdf
 
>>chenzhongshan
你的那个文档我看了,还是很不错的!但我现在的问题是服务器端的数据表不能做修改
并且采用的是CORBA结构,还要用java开发,服务器端的逻辑对以后的开发拓展以及效率
是至关重要的,现在的问题是如何对大数据的有效返回,序列化一个结构,还是使用octet
类型,那种情况可使效率得到提高!关键是效率
 
上楼:
都叫你不要灌了你还灌!呵
 
我也正在做这方面的尝试,希望能多交流.
在J2EE架构中,数据是通过使用ValueObject模式在各层中传递,而数据访问则是使用DAO模式,
这两个模式共同构建了数据访问层,数据访问层与业务层之间通过ValueObject联系起来.
我觉得这个ValueObject如何设计与DAO的设计是联系在一起的,我现在试图建立的数据访问层
是基于独立的主键生成策略,采用定制集合的方式,返回的仅仅是主键的一个collection,只有当
客户调用了read方法后才真正的读取相应的数据.
我之所以这样做是因为我找不到比较好的O/R Map方法,只好自己手工做,因此我的DAO使用了template
模式,自己写SQL,完成O/R Map.
我大概地分析了一下,这种做法的性能瓶颈在于连接池的大小和性能,因为所有的操作都是迅速释放连接
的,相对于数据处理过程,取得连接代价更为昂贵.
这种方式的优点是可以方便的控制数据的获得,减少无用数据的提取和传输,而商业逻辑和数据访问层可以
清晰的分开.
缺点也很明显,就是要多次的连接数据库,虽然时间短但并发问题没有彻底解决,只是减小了发生的几率.
我现在正为事务和并发这两个老问题伤脑筋,按理事务是不应在数据访问层解决,数据访问层应该是连接数据
库的底层事务处理与业务层的商业事务处理.另外还得自己写SQL,不够OO,不够自动化.
我现在的感觉是这些东西是牵一发而动全身,得从整个系统框架上来考虑.用不用EJB,这些问题的合适解完全
不一样,考不考虑移植又不一样,甚至选用什么数据库又不一样.
我碰到的问题和only you兄一样,但我想咱们选择的解法可能会完全不同,但也可以说是完全一样:都会使用DAO
和ValueObject,差别的产生在于实现DAO的方式,我选择JDBC和标准类,但也可以用EJB和JDO,最低层的实现不同
数据的返回方式也就不同,但所有的这些对业务层来说都应该是透明的
归根结底还是O/R Map的问题,这个问题的根源又在于Java在参数化数据类型上做得不够好--或者是我不会,还请
大家多指教.(我专门为此开了一帖 http://www.delphibbs.com/delphibbs/dispq.asp?lid=1511083)
咳,越抽象的解法越不能解决具体的问题,但却能越多的概括问题的实质.或许我们的价值就在于在将抽象的东西
具体化吧
only you兄,说错了还请多指正啊 ^0^
也说说你的想法吧,我也头疼着呢~~~~
 
COBRA我不会,我是当作和RMI一个性质的东西来理解,如果是这样的话,那么我想,用标准类的
方式或许比较好,但这时就得考虑自己处理事务和并发了
若是你的数据库设计是规范化的,且实体都用强实体定义,都定义了主键,那么利用数据库的
主键生成机制也很不错,只是这样就不便于移植,而且使用异质数据库时可能会有麻烦
 
楼主:是DELPHI乞儿。
请给我一些MONEY,我要成为DELPHI程序员。
 
only you ,你对游戏编程感兴趣吗?现有一个机会,偶在广东东莞,有一台胞想叫我开发游戏,
在互联网上玩的,他可帮忙谈判上台湾的著名游戏网站,可以来EMAIL谈谈(markiszml@163.com)
QQ123859090
 
我觉得delphi在多层这方面做的太差劲了,业务逻辑和视图很难达到真正的分离,
java 的多层架构是很不错,业务逻辑和视图之间可以传递valueobject;
 
jdbc3.0的rowset思想可以解决你的问题
大致思路是datasource->conn->sql得到所有数据->构造成rowset对象->web应用则构造为
WebRowset对象(内置xml格式转化api)->发送到客户端->客户端取值,或先变换格式为
xml后处理->发送回服务器端->更新数据构造成rowset对象->rowset.update更新数据
 
多人接受答案了。
 
后退
顶部