WCF +实体框架设计
我想知道如何设计得最好。
在我的 ASP.NET MVC 应用程序上，我有一个数据库，我想使用 WCF 通过 EF 处理与该数据库的所有交互。因此，我在服务上创建了一个实体模型，用于与数据库交互。为了从 ASP.NET 应用程序与 WCF 进行交互，我为每个 EF 模型（我只有 3 个）创建了 DTO，并创建了一个 Converter 类，用于从 EF 模型转换为 DTO，反之亦然。
顺便说一句..是否可以避免使用 DTO 而只传输 EF 模型？ - 我已经尝试过，但没有成功，因为客户端 asp.net 应用程序无法识别这些模型。
这是一种合适的设计方式还是其他方法会更好？
提前致谢。 :)
I was wondering how to design this best..
On my ASP.NET MVC application I have a database and I want to use a WCF to handle all my interaction with that database through EF. So I've create a Entity Model on the service which I use to interact with the database. In order to interact with the WCF from the ASP.NET app I've created DTO's for each EF model (I only have 3) and a Converter class to convert from the EF models to the DTO's and vice versa.
On a side-note.. would it be possible to avoid using DTO's and just transfer the EF models instead? - I've tried, but with no luck as the client asp.net app doesnt recognize these models.
Is this a suitable way of designing this or would another approach be better?
Thanks in advance. :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这种架构确实适用于业务逻辑和数据访问逻辑部署在另一台服务器上，然后部署在 ASP.NET 前端上的情况。这种架构的原因可能是公司政策、安全性、可扩展性等。但通常它是针对更大的项目。
你说你有3个“EF模型”。这是否意味着您有 3 个 EDMX 文件或 3 个实体？如果您的意思是 3 个实体，那么您的项目可能非常小，除非您确实必须使用此架构（直接要求），或者除非您只是做一些测试项目，否则没有理由这样做。
如何使用 DTO？它只是（或非常接近）到 EF 实体的 1:1 映射吗？在这种情况下，您错过了 DTO 的目的，并且您很可能不需要它们。如果您的服务公开 CRUD 操作，您可以直接使用 EF 实体（但必须使用 POCO 或 STE）。
此外，如果您只想将 EF 模型公开为 CRUD 服务，您应该检查 WCF 数据服务< /a>.
This architecture is indeed used in situations where business logic and data access logic is deployed on another server then asp.net frontend. Reason for such architecture can be company policy, security, scalability, etc. But usually it is for bigger projects.
You said that you have 3 "EF models". Does it mean that you have 3 EDMXs files or 3 entities? If you mean 3 entities than your project is probably very small and unless you really must use this architecture (direct requirement) or unless you are doing just some test project there is no reason to do that.
How do you use DTOs? Is it just (or very close) 1:1 mapping to EF entity? In such case you missed DTOs purpose and you most probably don't need them. If your service exposes CRUD operations you can use EF entities directly (but you must use POCO or STE).
Moreover if you just want to expose EF model as CRUD service you should check WCF Data Services.