看过Martin Fowler的Patterns of Enterprise Application Architecture的朋友请帮帮忙(200分)

小弟在看Martin Fowler的Patterns of Enterprise Application Architecture
（beta版书稿在www.martinfowler.com/isa/　2002年11月前有效）。但我对用
Domain Model + Data Mapper的组合理解得很模糊。也许是因为小弟没做过大型
项目（学生一名）。始终对“一记录一对象”这样的模式很没底：
１）在处理大量数据时是否会造成大量对象占用内存？
２）使用对象关系代替数据表关系是否真能很好地表达Business rule？因而值得使用这
　　样复杂的结构去实现对象关系和数据关系的转换？
希望有使用过类似模式的的大虾们谈谈心得。

1）如果数据量很大，那就不可能是一条纪录一个对象，而是要这个数据集看成是一个对象。
解决方法就是参数化，可以参考设计模式的微元模式。
2）事实上数据表关系表达的就是Business rule!，用对象关系来表达会更加清晰。一般设计时都要
商业建模和系统建模，商业建模就是分析和整理商业规则，系统建模就是把这些商业规则表现为
对象之间的关系，即数据库的逻辑设计，在进行数据库的物理设计时把这些关系映身成表之间的关系

我的一点浅见：
事实上是一条记录一个类，也就是把Record抽象为一个类，然后把整个表看作一个由“记录类”的对象组成的List。
DDK说的微元模式是否就是“Flyweight”模式？这个模式的一个典型应用就是Object pooling技术，用来解决大量对象占用内存的问题还是很合适的，关键是要把状态数据(即在多次调用之间持久保存的数据)放在外部，也就是放在Dataset中，这样就可以用一个或少量几个对象来存取整个表格了。具体请看GoF的《设计模式》。
至于最后一条我觉得主要还是看你的应用规模：
数据量大，效率要求高的应用可能采用较大的表格，这样的表格映射为对象比较困难。可以看看建立一些视图能否有所帮助。
小的应用可以直接采用面向对象的观点来组织数据表格，这样可能会有大量小表格并且和对象一一对应，也就是物理设计直接对应对象关系，但是存取效率可能不够理想。

多人接受答案了。

还有啊，我想Data Mapper可能是指一种可以根据数据库结构自动生成对象结构的代码生成工具，这样类代码就可以相对容易的建立了。