WCF 数据服务 - 代理中间层服务

2023-12-14

我们正在进行的项目是一个经典的三层架构。第 1 层是数据库服务器,第 2 层是应用程序服务,第 3 层是表示层(网站)。

在应用程序服务层中,我有一个项目,其中包括实体框架模型和基于 WCF 数据服务的服务,该服务公开模型中的实体,例如:

public class DataService : DataService< PortalEntities >

这是一个成熟的 OData 服务,可以通过 URI 进行查询,例如:/dataservice.svc/mytable?$filter=contains(fieldname,’string’)。这对于使用 jQuery 开发任何东西的人来说非常有用,因为他们所要做的就是定义查询。问题是该服务是中间层,因此外界无法看到。

我尝试的解决方案是在网站上公开另一个 WCF 数据服务,该服务公开由服务引用创建的实体。如果我向中间层服务添加服务引用,它会为我提供一个数据上下文,该数据上下文正在新的 WCF 数据服务中使用:

public class DataService : DataService< PortalEntities >

我确实必须覆盖 CreateDataSource:

protected override PortalEntities CreateDataSource()
{
    return new PortalEntities(GetMianModelServiceUri());
} 

新服务确实像代理一样,并返回暴露的实体(查询.../Services/OData/DataService.svc/tbl_Country工作正常)。

但是当查询传递给服务时,例如:.../OData/DataService.svc/tbl_Country?$select=Name它抛出一个未实现的异常。

关于如何扩展网站服务以使其支持与中间层服务相同的查询有什么想法吗?


如果您不需要更改数据服务器的形状或功能,您应该能够简单地转发请求和响应,就像透明的 HTTP 代理一样。您可能需要做的唯一区别是调整服务 URL。由于代理服务将具有与真实服务不同的基本 URI,因此有效负载将包含真实服务 URI(在链接等中),这是行不通的。您可以通过为实际服务使用自定义主机并对其 URI 撒谎来解决此问题。这是通过 IDataServiceHost2 接口完成的,您从 AbsoluteRquestUri 和 AbsoluteServiceUri 属性返回“新”URI。接口实现的一个很好的示例(尽管出于不同的目的)在这里:Link.

如果您需要改变形状或功能,那么您确实需要真正的分层。

目前,将一个 WCF 数据服务分层到另一个之上相当困难。 “服务器”生成的 LINQ 表达式树并不总是能被“客户端”LINQ 提供程序理解。这就是你遇到的情况。

有一个原型(更像是一个实验)可以通过重写表达式树来在某种程度上实现这项工作。它是 OData Provider Toolkit 的一部分,您可以在此处下载http://www.odata.org/developers/odata-sdk#/media/7579/odataprovidertoolkit.zip。 (它位于 AstoriaOverAstoria 项目的 Experimental 文件夹中)。

但请注意,这实际上只是一个实验,旨在展示需要解决哪些问题等等。我绝对建议不要在任何类型的生产环境中使用它。

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

WCF 数据服务 - 代理中间层服务 的相关文章

随机推荐