使用 POCO 的任何缺点 +实体框架跨层而不使用数据传输对象？
跨层（DAL、BLL 和表示）使用相同的 POCO（在 EF4 和 WCF 中）并且不使用 DTO 是否有任何缺点？客户端和服务都是 .NET 和 .NET 的。整个应用程序并不是特别大。
我问这个问题是因为在不同格式的层之间移动相同的数据并进行转换和映射似乎很麻烦。增加了复杂性。开发、维护、维护比较耗时。很容易出错。我不确定添加 DTO 是否值得，即使 DTO 是在运行时生成的或使用了 DTO 生成器。
当我开始设计和制作时，我想看到一些意见。编写一个新的网络应用程序。
Are there any disadvantages for using the same POCOs (in EF4 & WCF) across the tiers (DAL, BLL & Presentation) and doing without DTOs? The clients and services are all .NET & the whole app is not extra big.
I ask this because moving the same data between the tiers in different formats and doing conversions and mappings seems like a hassle & adds complexity. It's more time consuming to develop and maintain & is prone to errors. I am not sure if adding DTOs is worth it, even if the DTOs are generated during runtime or DTO generators are used.
I would like to see some opinions as I am starting to design & code a new web app.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
使用 DTO 的主要动机之一是需要通过网络传输对象表示。
如果您在单个进程中使用域模型对象，那么您可能只需要在整个过程中使用相同的对象就可以了。
另一方面，如果您计划序列化对象并将它们发送到其他进程（例如通过 Web 服务），那么通常最好使用 DTO 来执行此操作，其形式同意 两个进程之间的数据契约。 数据注释可用于丰富本合同协议。两个进程都可以使用相同的数据协定程序集进行序列化和反序列化。
这种架构中的每个进程可能有不同的目的（因此分离），因此对对象有不同的要求，例如，一个可能是仅与表示相关的 GUI，一个可能是与改变对象，允许它们在遵守业务规则的同时进行交互，另一个可能是只关心持久性的数据访问层，另一个可能是关心为报告引擎转换对象的反规范化器，等等。这意味着唯一可能的共性各层之间的要求是数据表示，即 DTO 或数据契约，而不是富域模型对象的行为。在给出的示例中，唯一需要具有丰富行为的对象的层是业务逻辑层。
如果您需要这样做，DTO 也可能是在 AppDomain 之间传输对象表示的更好方法。
One of the main motivations for using DTO's is the need to transfer object representations across the wire.
If you are using your domain model objects within a single process then you may well be ok just using the same objects throughout.
If, on the other hand, you are planning to serialize your objects and send them to other processes, e.g. via a web service, then it's usually better to do this using DTO's which form agreed data contracts between the two processes. Data annotations can be used to enrich this contractual agreement. Both processes can potentially use the same data contract assembly to serialize from and deserialize back to.
Each process in such an architecture is likely to have a different purpose (hence the seperation) and will, therefore, have different requirements from the objects, e.g. one may be a GUI concerned with presentation only, one may be a business logic layer concerned with mutating the objects, allowing them to interact whilst adhering to business rules, another may be a data access layer concerned with only persistence and another may be a denormalizer concerned with transforming the objects for a reporting engine, etc. This means that the only likely commonality in requirements between the layers is the data representation, i.e. DTO or data contract, rather than the behaviours of a rich domain model object. In the examples given, the only layer which needs a rich object with behaviours is the business logic layer.
DTO's may also be a better way to transfer the object representations between AppDomains, if that is something you are required to do.
跨网络意味着您的数据跨网络可见。
一旦用户成功通过身份验证，任何网络工具都可以泄露所有传递的数据。如果您传递整个实体并且在用户界面中仅显示实体的过去，那么您就假设用户不会看到您的隐藏数据。但使用任何网络跟踪工具，一切都是可见的。
您必须想象您实际上正在发送完整的数据，而 UI 只是一个演示。
因此，如果用户可以通过网络跟踪看到数据，那么就没有什么可担心的。
但请记住，一些恶意的人可能会尝试操纵数据，考虑到用户永远无法访问它，您可能会忽略这些数据。例如，您可以将用户名设置为只读字段，并且您的 ui 将不允许用户修改，但有人可以轻松编写 wcf 客户端代码来连接到您的服务。
大多数问题都是由于外键而发生的，如果有人操纵外键，将很难验证对象的所有权。
您必须假设网络上的每个请求都是有害的，并且必须检查所有可能性的安全性。
Across the wire means your data is visible across the wire.
Once user has successfully authenticated, any network tool can reveal all the data that is passed. If you are passing entire entity and you are showing only pasts of entity in the ui then you are under assumption that user will not see your hidden data. But with any network trace tool, everything is visible.
You have to imagin that you are actually sending complete data and UI is just a presentation.
So if it is ok for user to see the data through network trace, then there is nothing to worry.
But remember some one with bad intention may try to manipulate data, that you may have ignored considering user will never have access to it. For example, you may make a username readonly field, and your ui will not allow user to modify but someone can easily write wcf client code to connect to your service.
Most problems happen because of foreign keys, if anyone manipulates foreign keys, it will be difficult to verify ownership of object.
You must assume that every request on wire is and will be harmful and security must be checked for all possibilities.
缺点开始了，这只是一个例子，但想象一下你的 UI 设计师提出了一个简单而无辜的问题。我们不能将实体在屏幕上绘制的 x 和 y 位置存储在实体本身中吗？我不能在实体上有一个“选定”属性来指定它当前是否被选择吗？你会想：精选房产，天哪！我不可能将其写入数据库，这没有任何意义。然后他们希望您的 POCO 实现 INotifyPropertyChanged 并获取一些自定义事件等。
DTO 和映射的优点是解耦层。您正在提高根据每一层的要求自定义对象的能力。
现在有一些简洁的绘图工具可以使这项任务变得非常容易。 AutoMapper 就是其中之一。 使用 T4 模板生成代码是另一种情况。
The disadvantage starts and this is just an example, but imagine your UI designer comes along with a simple and innocent question. Can't we store the x and y position of where the entity is drawn on the screen in the entity itself? Can't I have a "Selected" property on the entity that specifies if it is currently selected or not? And you think: A Selected property, hell no! I can't possibly write that to the database, that doesn't make any sense. And then they want your POCO to implement
INotifyPropertyChangedand get some custom events and so on.The advantage of DTOs and mapping is to decouple your layers. You're improving your ability to customize your objects for the requirements of each layer.
There are some neat mapping tools nowadays that should make this task pretty easy. AutoMapper is one of them. Codegeneration with T4 templates is another.