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