问题标签 [servicecontract]

我正在寻找正确的写出为什么我们需要在 WCF 中使用接口作为服务合同的原因。我得到了这个 url为什么 .net WCF 服务需要接口，从这里我知道我们可以在类而不是接口上编写服务合同属性。

配置条目

但是非常失望的是没有得到所有正当理由，例如人们为什么经常使用接口作为服务合同？

所以只要告诉我当我们使用接口作为服务契约时我们得到的所有好处。所以寻找使用接口作为服务合同的所有有效点。所以也给示例场景加分，因为为了更好地理解。谢谢

我有一个使用 NetTcpBinding 的 WCF 服务，我想将它托管在 WPF 应用程序中。该服务似乎可以正确启动，但是当我尝试在 Visual Studio 中使用“添加服务引用”获取它的元数据时，我得到了这个异常：

我的服务项目的 App.config 文件：

以及托管应用程序中的代码：

我发现该问题的解决方案主要是将“serviceMetaData”添加到服务配置或提供 mex 端点。你能建议点什么吗？

编辑：

最终配置：

托管应用程序：

我从客户端进行 WCF REST api 调用。为此，我使用了一个类型的专用对象WebChannelFactory<IRestApi>，其中IRestApi是一个 ServiceContract。

然后，我可以通过我使用的通道（由创建）调用 IRestApi 的方法CreateChannel()。

我的问题是：我可以向这个通道添加常量参数（在我的情况下是版本号），这样我就不必在每个调用中一遍又一遍地传递它？

我有一个 wcf 服务，我将其设置为 restfull，但编辑接口和 webconfig。在界面中，我有以下内容：

我想是否可以以这种方式调用 webservice 函数：

http://foo.example/api/v1/accounts/3

我希望我的函数 URL 链接看起来不像这样：

http://servername.com/MyApi/MyApi.svc/AddPerson - 意思是我不想拥有 SVC 扩展。这有可能吗？

我怀疑我必须使用服务合同命名空间，但我找不到程序是什么？

我想创建一个实现 2 个服务合同并在不同端口上公开 2 个端点的类（我将端口作为程序的输入）。

我的问题与这个问题非常相似，但我想要两个端点，每个端点都在不同的端口上。

编辑：

使用此代码：

我在 host.Open() 操作上收到此错误消息：

解决方案

我的类Request派生自Dictionary<string, string>. 它有额外的字段。然后我有服务合同：string MakeRequest(Request request); 之后我为此合同生成服务参考。但是 VS 出于某种原因会生成下一个代码：

我的问题是如何告诉 VS 我想要派生类而不是基类。

我已经为我的 Web-API 实现了 OdataController(s)。是否可以使用 ChannelFactory（或 WebChannelFactory）与 Web-API 进行通信，特别是我想调用自定义函数和/或操作。

当然，我创建的 OdataController 确实实现了 ServiceContract。但我不确定这是否可能因为 url/命名空间。

反序列化请求时，我得到一个非空但为空的字典。

我要发布的对象：

这是我随请求发送的正文：

内置序列化程序创建一个Data空的对象Dictionary。Newtonsoft 序列化程序的行为符合我的要求。因此，经过一番谷歌搜索后，我将服务合同更改为接受 aStream而不是Data.

这里的主要问题是，如果我指定 header ，则不再接受请求Content-Type: application/json，这显然是我想要的，但如果提到方法签名也会很好Data。

如何为我的服务指定自定义反序列化器？或者，如果不可能，即使指定了 Content-Type，也要使当前解决方案工作？

也许它是重复的，但我无法成功找到所需的答案。

实际上，我正在尝试构建通用包装器，以便通过 wcf 使用 Entity/L2Sql。所以在服务器端：

在客户端我这样使用

我了解 WCF 为通用的东西、不同的语言创建了什么，并且自然禁止直接 T，但也许有一种方法可以用一些属性或描述来解决这个问题（比如 where T:DataContractAttribute，但这是无效的）。

或者我开始想错了=）

对于某些视图模型，我需要每个视图模型一个 DbContext，而不是使用 (..dbcontext..)

我们在系统中遇到了一个god object。该系统包括public service向我们的客户公开，middle office service以及back office service.

流程如下：用户在 中注册一些交易public service，然后经理从middle office service检查交易并批准或拒绝交易，最后经理从back office service完成或拒绝交易。

我正在使用这个词transaction，但实际上这些是不同类型的操作，例如CRUD on entity1，CRUD on entiny2...不仅是CRUD操作，还有许多其他操作，例如approve/send/decline entity1，make entity1 parent/child of entity2等等...

现在WCF服务合同只是根据系统的那些部分分开。所以我们有3个服务合同：

和巨额的运营合同在每个：

所有 3 项服务的运营合同数量已经达到 2000 个，每个服务合同大约有 600 个。这不仅破坏了最佳实践，而且由于需要很长时间才更新服务引用是一个巨大的痛苦。并且系统每天都在增长，并且在每次迭代中向这些服务添加越来越多的操作。

而现在我们面临着两难境地，我们如何将这些上帝服务拆分成逻辑部分。有人说一个服务不应该包含超过 12~20 个操作。其他人说一些不同的话。我意识到没有黄金法则，但我只是希望听到一些关于此的建议。

例如，如果我只是按实体类型拆分这些服务，那么我可以在项目中获得大约 50 个服务端点和 50 个服务引用。在这种情况下，可维护性如何？

还有一件事要考虑。假设我选择将这些服务拆分为每个实体的方法。例如：

public client现在发生的事情是我应该在和中添加对该服务的引用back office client。但back office只需要FinalizeEntity1和DeclineEntity1操作。Interface segregation principle所以这是一个经典的in违反SOLID。因此，我必须将其进一步拆分为 3 个不同的服务，例如IEntity1FrontService, IEntity1MiddleService, IEntity1BackService.