实体框架使用传输对象通过 WCF 发送
我正在读这本关于 WCF 服务的书。它所说的是创建一个包含数据库实体模型的 WCF 服务。例如，假设该数据库有一个名为 User 的表。然后，作者创建了一个名为 UserDto 的新类，其中包含与 User 数据库表中几乎完全相同的字段。他说，这样做的原因是，当通过 WCF 传递数据时，您不想传递实际的实体创建的对象，因为它包含不需要的数据（并占用带宽）。
我想知道的是，是否有某种类生成器可以为我构建这些传输类？如果我有一个包含 10 个或更多对象的数据库，我不想在业务层中对 10 个对象进行硬编码。有没有一个工具可以为我做这样的事情（即代码生成器）？
或者有人可以建议更好的方法吗？
I was reading this book about WCF services. What it said was to create a WCF service which contained an entity model of the database. For example, lets say this database had a table called User. The author then went to create a new class called UserDto which contained almost exactly the same fields as those in the database table for the User. The reason, he said, for doing this was that when passing data through WCF you don't want to pass the actual entity created object as it contains data that is not needed (and uses up bandwidth).
What I wanted to find out, is there some kind of class generator in order to construct these transport classes for me? If I have a database of 10 or more objects I don't want to sit and hard code 10 objects in the business layer. Is there a tool that can do something like this for me (i.e. a code generator)?
Or can anyone suggest a better way of doing this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
使用 POCO 对象就可以了。但是，如果您想将普通 EF 生成的对象用于 DTO，那么绝对没有理由不这样做。它们是专门为与 WCF 配合良好而设计的，因此除非您的表有大量您不希望看到的列发送到客户端，否则通过使用 EF- 来简化您的代码和生活是完全合法的。生成的类。我们正是在相当大的 WCF 服务（约 5000 行代码，约 30 个实体）上执行此操作，并且我们没有遇到使用单独的数据层可以解决的任何性能或体系结构问题。
我的一般经验法则是：只有当很明显不这样做会给你带来很多麻烦时，才在你的架构中添加一个额外的层。任何可以合理消除的层都可以消除。
Using POCO objects is fine. But if you want to use the normal EF-generated objects for DTO, there's absolutely no reason not to. They were specifically designed to play well with WCF, so unless your tables have a very large number of columns that you don't want to see sent down to the client, it's perfectly legitimate to simplify your code and your life by using the EF-generated classes. We're doing precisely this on a reasonably large WCF service (~5000 lines of code, ~30 entities), and we haven't run into any performance or architectural problems that using a separate data layer would have solved.
My general rule of thumb: only add an extra layer in your architecture when it becomes really obvious that not doing so will cause you a lot of headache. Any layer that you can reasonably eliminate, do so.
查看 EF 对 POCO 的支持。还有一个 POCO 模板，它将根据 EDMX 中定义的模型生成这些 POCO 对象。
EF 和 POCO
Take a look at EF support for POCO. There's also a POCO template that will generate those POCO object based on the Model defined in the EDMX.
EF and POCO
了解 T4 代码生成器，它自 2008 版以来一直是 Visual Studio 的一部分。
它可以执行以下操作：诸如此类的事情。实际上：EF 代码生成模板（用于 POCO 和自跟踪实体）都是 T4 模板...例如，用于在 ASP.NET MVC 中生成视图的模板也是如此。
开始使用 T4 的优秀资源：
使用 T4 模板生成代码 – A开发人员必备
在 VS2010 中自定义实体类
实体框架中的 T4 模板
T4 模板上的截屏用于 ASP.NET MVC
以及更多网站，如果您去询问您的朋友 Bing 和 Google :-)
Read about the T4 code generator that's been part of Visual Studio since version 2008.
It can do things like that. Actually: the EF code generation templates (for POCO and self-tracking entities) are all T4 templates... as are the templates for generating views in ASP.NET MVC, for instance.
Excellent resources to get started with T4:
Code Generation with T4 Templates – A must have for developers
Customizing Entity Classes in VS2010
T4 templates in Entity Framework
Screencast on the T4 templates used in ASP.NET MVC
and a great many more sites, if you go ask your friends Bing and Google :-)
http://visualstudiogallery.msdn.microsoft.com/23df0450-5677-4926 -96cc-173d02752313
这正是我正在寻找的！
http://visualstudiogallery.msdn.microsoft.com/23df0450-5677-4926-96cc-173d02752313
This was exactly what I was looking for!