在各层（DAL，BLL和演示文稿）中使用相同的POCO（在EF4和WCF中）和没有DTO时是否有任何缺点？客户端和服务都是.NET＆amp;整个应用程序并不是特别大。
我问这个问题是因为在不同格式的层之间移动相同的数据并进行转换和映射似乎很麻烦。增加复杂性。开发和维护＆amp;很容易出错。我不确定添加DTO是否值得，即使在运行时生成DTO或使用DTO生成器也是如此。
我希望看到一些意见，因为我开始设计＆amp;编写新的网络应用程序。
答案 0 :(得分：3)
使用DTO的主要动机之一是需要通过线路传输对象表示。
如果您在一个进程中使用域模型对象，那么您可以在整个过程中使用相同的对象。
另一方面，如果您计划序列化对象并将其发送到其他进程，例如通过Web服务，通常最好使用在两个进程之间形成约定data contracts的DTO来完成此操作。 Data annotations可用于丰富此合同协议。这两个进程都可能使用相同的数据协定程序集从序列化和反序列化返回。
这种架构中的每个过程可能具有不同的目的（因此分离），因此将具有与对象不同的要求，例如，一个可能是仅涉及呈现的GUI，一个可能是涉及变异对象的业务逻辑层，允许它们在遵守业务规则的同时进行交互，另一个可能是仅涉及持久性的数据访问层而另一个可能是非规范化的关注转换报告引擎的对象等。这意味着层之间需求中唯一可能的共性是数据表示，即DTO或数据契约，而不是富域模型对象的行为。在给出的示例中，唯一需要具有行为的富对象的层是业务逻辑层。
DTO也可能是在AppDomains之间传输对象表示的更好方法，如果这是您需要做的事情。
答案 1 :(得分：1)
通过电线意味着您的数据在电线上可见。
用户成功通过身份验证后，任何网络工具都可以显示所有传递的数据。如果您正在传递整个实体并且您只在ui中显示实体的过去，则您假设用户不会看到您的隐藏数据。但是使用任何网络跟踪工具，一切都可见。
你必须想象你实际上是在发送完整的数据而UI只是一个演示文稿。
因此，如果用户可以通过网络跟踪查看数据，那么无需担心。
但请记住，有一个意图不好的人可能会尝试操纵数据，你可能会忽略，因为用户永远无法访问它。例如，您可以创建用户名readonly字段，并且您的ui将不允许用户修改，但有人可以轻松编写wcf客户端代码以连接到您的服务。
大多数问题都是因为外键发生的，如果有人操纵外键，就很难验证对象的所有权。
您必须假设线路上的每个请求都是有害的，并且必须检查所有可能性的安全性。
答案 2 :(得分：1)
缺点开始，这只是一个例子，但想象一下你的UI设计师带来了一个简单而无辜的问题。我们不能存储实体本身在屏幕上绘制实体的位置的x和y位置吗？我不能在实体上有一个“Selected”属性，指定它当前是否被选中？你认为：一个选定的财产，不，不！我无法将其写入数据库，这没有任何意义。然后他们希望您的POCO实现INotifyPropertyChanged并获得一些自定义事件等等。
DTO和贴图的优势在于解耦图层。您正在提高自定义对象以满足每个图层要求的能力。
现在有一些巧妙的地图绘制工具可以让这个任务变得非常简单。 AutoMapper就是其中之一。带有T4模板的Codegeneration是另一个。