我们正在开发一个WCF REST服务,它将被桌面WPF应用程序使用,并且也将成为ASP MVC4网站的数据源。
到目前为止,我遇到了无数的技术问题,最重要的是我担心Microsoft.OData.EntityFrameworkProvider的未来。 (请查看博客评论here)。
问题包括:
没有简单的方法(不使用DTO)在服务实体上添加属性,这些属性将通过OData传递,但不会存储在数据库中实际上有一个简单的方法:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.ComplexType<CustomType>();
}
没有简单的方法(没有解析XML或使用DTO)在客户端实体上存储属性而不将它们发送到服务(v5.6.0)。 &#34;硬&#34;方法是挂钩到RequestPipeline和ResponsePipeline:
Configurations.ResponsePipeline.OnEntryEnded(OnReadingEntry);
Configurations.RequestPipeline.OnEntryEnding(OnWritingEntry);
使用DTO至少说起来很麻烦,automapper有助于检索IQueryable结果,但更新实体需要IUpdateable的完全实现,这实际上可以在DTO上运行,但需要更新实体,因此如果实现它是非常棘手的甚至可能(我搜索现有的解决方案,这些主要涵盖在内存数据源中,所以我实现了一个有效的解决方案,但没有链接,如果有人感兴趣,我可以从源代码控制中挖掘它)。在v5.6.0上测试。
此套餐近半年没有更新,这个事实本身就非常令人担忧。
我的问题是,EF上下文和客户端之间的Microsoft.OData.EntityFrameworkProvider链接的Microsoft或开源替代品是否适合替换这个假定的死库?这种链接的关键要求是拥有跟踪客户端上下文和实体框架5或6兼容服务。
Microsoft.AspNet.WebApi.OData对桌面应用程序也是一个很好的解决方案吗?
是否有其他Microsoft或开源项目具有类似功能?
答案 0 :(得分:2)
对于WCFDS更新,您可以参考Future Direction of WCF DS service。
在您列出的问题中,我确信问题1可以通过标记[IgnoreDataMember],here在Web api中轻松解决。
对于问题2和4,一个建议是你可以在客户端添加一个数据层,它可以处理额外的数据模型和动态字段
答案 1 :(得分:0)
只是几个想法...... REST与OData不同......所以你的问题很混乱。如果您的意思是WCF数据服务,那么一定要使用新的WebApi。正如Maya的链接所示,WCF DS团队宣布他们基本完成了。
但是,您的客户通常不了解您使用的odata及其数据层的技术......它是一个断开连接的架构。因此,如果你在服务器端有一个映射阻抗,这是一个问题,但哪个客户端消耗odata应该是无关紧要的。但是我可能没有正确理解你陈述的问题...你的意思是你拥有客户端和服务器并希望共享实体类定义吗?如果您是紧密耦合的,您可以添加为客户端定制的服务资源,以及为您的MVC应用程序定制的其他服务资源。
对于一些实际的解决方法,WCF DS提供了查询拦截器,可让您操作传出数据。新的WebApi基本上来自控制器,可让您完全控制拦截请求并操纵需要对数据执行的操作。
最后,只是对您的桌面客户端的一个建议...... Lightswitch使用oData工作奇迹...指向并点击...它可以动态生成您的代理和客户端模型,让您可以对客户端进行巨大的控制以及它是什么与服务器的响应有关。