背景
我们有自己的业务对象架构，一个更轻量级的（...并且松散地基于，但实际上并没有使用...）版本的“CSLA”业务对象框架，具有类似的用法、验证、包容性 DAL 等。所有生成代码（使用 CodeSmith 创建存储过程和业务对象）
业务对象在获取对象、具有过滤排序参数的列表以返回对象和通用列表的功能方面非常丰富。
这种架构可能不支持一种特定或流行的架构和纯粹主义，但它对我们来说效果很好，并且减少了很多手动编码。
我们发现很多的一件事，特别是在与其他系统（第 3 方、Flash 或 Silverlight 等）集成时，需要上下文化的“基本对象”或数据容器，这些容器可以轻松地序列化并跨 Web 服务等提供以用于特定目的。
环顾 SO 和网络，术语 DTO 出现了很多。我们在 Dto 命名空间中创建了这些基本对象，这些对象是代表基本或特定版本的业务对象的基本对象，但除了接受 DataRow 或业务对象以填充“Dto”对象的构造函数之外没有其他功能。
问题：
1)将其称为“DTO”对象是否正确？
2）与其让构造函数提供数据和设置对象属性，不如让这个填充代码在不同的类中，某种“帮助类”
关于我正在尝试做的术语和命名约定的任何评论？
谢谢