问题标签 [contract]

我有一个 wcf 服务，它在单个端点地址上公开了大量的服务方法。到目前为止，所有服务方法都在单个服务合同类中实现。这个服务契约类实现了几个服务契约接口。现在我想将服务契约方法的实现拆分成几个类，以避免契约类变得很大。我使用带有 ServiceHost 的自托管方案。ServiceHost 只采用实现服务方法的单一类型的类型，因此似乎所有内容都必须在此类中实现。当然，这些方法的实质可以分解为几个类。但是有没有办法将方法分成几个类？

我正在尝试在 iTunes Connect 中设置合同，但我所拥有的只是免费合同。我没有设置新合同的选项。

任何人有任何想法为什么？

斯蒂芬

我的问题是：有一段这样的代码（通过回调合约进行通信）

和一个回调合约

我是否有保证消息将成功广播给所有客户端，即使有一些，比如说网络问题？我的意思是，服务是否会自动尝试一次又一次地传递消息，直到它成功，假设客户端一直处于连接状态，但在第一次传递过程中出现了一些问题。我问是因为我不知道是否必须编写额外的代码才能保证它（服务客户端确认消息等）我在 app.config 中启用了可靠会话，可靠会话是否解决了问题？

提前感谢您的回答

我决定我要学习制作网站的技能，希望有一天能从事合同工作。目前我正在涉足 Django，但我的印象是大多数合同工作都是用 PHP 完成的。这是为什么？

背景：

我们正在为新的嵌入式系统建模固件。目前固件正在 UML 中建模，但不会使用 UML 建模工具的代码生成功能。

目标语言是 C（具体来说是 C99）。

低功耗（即性能、快速执行）和正确性很重要，但正确性是重中之重，高于一切，包括代码大小和执行速度。

在对系统建模时，我们已经确定了一组定义明确的组件。每个组件都有自己的接口，并且许多组件与许多组件交互。

模型中的大多数组件将是实时操作系统 (RTOS) 下的单个任务（线程），尽管有些组件只不过是库。任务完全通过消息传递/队列发布相互通信。与库的交互将以同步函数调用的形式进行。

因为建议/建议可能取决于规模，所以我将提供一些信息。现在可能有大约 12-15 个组件，可能会增长到大约 20 个？不是 100 多个组件。假设平均而言，每个组件与 25% 的其他组件交互。

在组件图中，有端口/连接器用于表示组件之间的接口，即一个组件提供另一个组件所需的东西。到目前为止，一切都很好。

这就是问题所在：在很多情况下，我们不希望“组件 A”能够访问所有“组件 B”的接口，即我们希望将组件 A 限制为组件 B 提供的接口的子集。

问题/问题：

是否有一种系统的、相当直接的方式来执行——最好是在编译时——在组件图上定义的接口契约？

显然，编译时解决方案比运行时解决方案更可取（更早的检测，更好的性能，可能更小的代码）。

例如，假设库组件“B”提供函数 X()、Y() 和 Z()，但我只希望组件“A”能够调用函数 Z()，而不是 X() 和 Y() . 同样，即使组件“A”可能能够通过其消息队列接收和处理大量不同的消息，我们也没有任何组件能够向任何组件发送任何消息。

我能想到的最好办法是为每个组件-组件接口设置不同的头文件，并且只公开（通过头文件）组件允许使用的接口部分。显然这可能会导致大量的头文件。这也意味着组件之间的消息传递不会直接使用 OS API 完成，而是通过函数调用完成，每个函数调用都会构建并发送特定的（允许的）消息。对于同步调用/库，只会公开允许的 API 子集。

对于这个练习，你可以假设人们会表现得很好。 换句话说，不要担心人们直接作弊和剪切和粘贴函数原型，或者包含他们不允许的头文件。如果不允许，他们不会直接从“A”向“B”发布消息，依此类推……

也许有一种方法可以通过编译时断言来强制执行合同。也许有一种更优雅的方法可以在运行时检查/执行它，即使它会产生一些开销。

代码必须干净地编译和 lint，所以“函数原型防火墙”方法是可以的，但似乎可能有一种更惯用的方法来做到这一点。

换句话说：如何更改 wcf 服务合同以从肥皂消息中删除额外的“消息”包装（采用 wsdl）？

我创建了 WCF 服务，合同是：

所以我的 SC 现在接受这样的消息

但旧版客户端发送此类消息（消息的epr:e级别丢失）

行。我从零开始创建“wsdl”，首先删除了消息包装器，然后生成了示例合同（cs）。我可以看到生成的代码在生成的消息类附近使用 MessageContract.IsWrapperd=false，但我无法更改生成的代码，所以 . 我应该以某种方式更改操作合同，并要求 wcf 使用正确的 MessageContract 为我生成消息。

我有这个 WCF 服务合同（非常简化，但要注意它所在的命名空间）：

在我的app.config（客户端）中，我为某些服务配置了一个端点：

但是，这会导致错误提示在客户端的配置中未找到支持BarService.BarContract. 我只能通过将contract属性值更改为BarService.BarContract（即通过删除命名空间）来摆脱这个错误。

这是为什么？这个错误可能来自哪里？为什么我不能提及合约类型的命名空间部分？这不应该导致 WCF 找不到匹配的端点吗？

回复下面@Ladislav Mrnka 评论中的问题：

• 我说的是客户端。（我忘了提到这一点；对此感到抱歉。）这个错误可能来自服务器端吗？

• 我通过 Visual Studio 的添加服务引用工具生成了上述服务合同以及BarClient实现它的类。我指定了由其他人运行的 URL 。那就是我还指定应该将服务放在命名空间中的地方。BarServiceFoo.Services.BarService

• 我打算通过为我自动生成的类直接使用该服务BarClient，而不是通过ChannelFactory<BarContract>.

我正在使用 Core Data 映射关系的想法。

我有一个Employer与 具有多对多关系的实体Employees。基本上，一个雇员可以为多个雇主工作，一个雇主可以有多个雇员。

我面临的问题是，我不确定如何管理雇员和雇主之间的合同。

由于员工可以为一个或多个雇主工作，他们自然会为他们工作的每个雇主签订一份合同（包括工资、工期）以及他们为特定雇主工作的日期列表。

我的问题是 - 如何管理雇主和雇员之间Contracts的关系？ContractDates

谢谢你。

图像如下。

我对在类似 CRUD 的操作上应用 Larman 的系统操作合同（来自应用 UML 和模式一书中的 OO 分析）有些困惑。更准确地说，我对后置条件部分感到困惑。

例如，如果我的 CRUD 系统操作如下所示：

例如，readEmployee系统操作或其他类似操作的后置条件是什么searchEmployees？

例如：对于读取操作，系统需要从数据库中读取记录，实例化域对象，在域对象上设置属性值（也设置关系），仅此而已。这是否意味着上面提到了后置条件-实例创建，属性更改等。或者，读取操作没有任何后置条件。这些对我来说都不合逻辑。

我的困惑是关于域模型（状态）和数据库（状态）之间的关系。我只是没有得到上述操作对域模型的影响。我一直认为数据库是保存系统状态的地方。创建员工后，其对象的状态将保存在数据库中......但是域模型状态会发生什么？

我的骰子模拟器会根据用户的输入和模型改变其 UI。我一直在尝试实现 Builder 模式来处理变化和可选参数，同时允许使用 GroupLayout。

目前我正在控制器中进行这样的调用：

我讨厌 if 语句，因为它们种类繁多。谁能帮我理解我可以使用什么抽象或合同或接口来干净、准确地在 MVC 中构建所需的 UI？