一个业务逻辑层与持久层交互 接口设计问题
当业务层获知一个来自表现层的数据库操作时，一般采用什么设计策略使得业务层能很好把请求委托给持久层，一般持久层需要哪些组件支持（类），怎么定义持久层服务使得业务层不关心持久化操作而只知道业务对象，达到高内聚低耦合效果。

比如：获知一个查询表的操作时，业务层一般做哪些操作（持久层服务）递交查询操作给持久层，并获得数据记录集。
在业务层和持久层的设计中都有哪些需要注意的一般问题或者技巧，才能做到后期可扩展可维护。
若有经验者，大牛们 能指点一二，感激不尽！！！！！！！！期待。。。

[解决办法]
我是隔壁来的，我的帖子一天了没人回帖。
一看你这个帖子的时间差，心就凉了。。。

说说我的看法。
我觉得下面这句有问题，我们就从这一句展开：
当业务层获知一个来自表现层的数据库操作时。。。。


表现层是不会知道什么叫做数据库操作的，它只会知道给我数据，比如GetMemberList...
它向谁要呢，向业务层要，业务层是从数据层那边取还是自己放在内存中，表现层不管。
业务层是肯定要知道持久化操作的，只不过持久化操作你可以把它弄成接口，具体的实现由具体的持久化实现（比如持久化到数据库，持久化到文本，持久化到远程机子）


而在各个层之间传递数据时可以通过对象模型，比如GetMemberList返回的事Member的List，Member就是一个业务逻辑对象，数据层取数据返回业务层时也要用这种参数，而不能是原始的什么int。。。

好像太杂了，将就看吧
我那贴估计得锁了。

[解决办法]
我被这个问题折腾很久了，估计还将继续折腾下去

我们希望的业务逻辑层是以实体、业务为视角的，我们希望这些接口能够很优雅地复用，这就要求逻辑上非常的优雅，可是往往你会发现，逻辑上好了，性能上差，性能好了，逻辑上就难看。这是因为数据库存储是另一个视角，反映的是物理的机器世界视角。

很多时候，逻辑和物理就是冲突的，理想和现实就是有差异的。没有最优解！