三层架构新问题

Question

使用三层架构时，数据访问层获取到的数据集是否要封装成实体 （比如分页时数据应该在10-20条）
这样封装成实体是会有性能上的损耗，但是不这样做不就失去三层的意义了吗，不就成了紧耦合？
请问各位大侠是怎样处理的？

Answer 1

如果你从数据库向上去理解业务、表现，你永远会有各种各样的不服气。如果你多一些开发经验，凡事开发都从业务从入手设计，并且先写出界面和业务层的匹配关系，然后再写数据访问方面的代码，你就会很自然地觉得那些满篇重复的调用数据库操作api的代码（只是针对的数据库内部对象不同，代码非常类似）是冗余的、不方便应付千变万化的业务逻辑改变的（当业务逻辑改变时，你不能几秒钟就生成新的系统，而需要花十几分钟去重写底层代码）。

Answer 2

实体不实体的不是分层的重点，我倒是觉得直截了当地说明你的“通用”数据库编程接口是传统的关系数据库api还是面向对象ORM接口更好。当你选择一个对象数据库系统，如果它要求你设计出实体，说明他接下来就能自动保存、删除、查询这些实体，而无需你写更底层的代码。如果你只是从理论上听说“要分层、要实体”，你的对实体的后续处理还是自己面向底层的数据库api而手写的，分层只能是比以前更麻烦。那些千方百计废弃自己所“精通”的数据库api的人，才能找到更好的数据库工具。如果你保定底层数据库编程为根本，任何数据抽象、自动化，你都会害怕丢失自己的优势。

Answer 3

引用 10 楼 sp1234 的回复: 
实体不实体的不是分层的重点，我倒是觉得直截了当地说明你的“通用”数据库编程接口是传统的关系数据库api还是面向对象ORM接口更好。当你选择一个对象数据库系统，如果它要求你设计出实体，说明他接下来就能自动保存、删除、查询这些实体，而无需你写更底层的代码。如果你只是从理论上听说“要分层、要实体”，你的对实体的后续处理还是自己面向底层的数据库api而手写的，分层只能是比以前更麻烦。 
… 学习了

Answer 4

sp1234每次都是引经论点让我们这些刚入门的coder摸不着头脑，回答那么多理论上的，而我从中得不出任何结果！
其实你可以先告诉个结果然和在进行申论。相信这样更易懂！