.net 4.0 代码合同。什么时候使用？他们什么时候浪费时间？答案

【问题标题】：.net 4.0 Code Contracts. When to use? When are they a waste of time?.net 4.0 代码合同。什么时候使用？他们什么时候浪费时间？
【发布时间】：2010-06-24 15:18:11
【问题描述】：

我一直在研究 .NET 4.0 代码合同并查看 stackoverflow 以及有关此的问题。

我仍然没有遇到任何使用代码契约的示例代码，这让我想知道.. 这真的有用吗？或者也许它唯一有用的一个你的代码达到了一定的复杂性？有人在使用代码合同并且真的很高兴他们这样做了吗？

在我看来，所有代码合同都是关于方法的输入和输出的断言，此外还能够尝试找出在编译时输入和输出的值......但随后这将需要您所有方法的更多代码..值得吗？

我注意到的一个好处是，在我看来，您可以使用代码契约作为单元测试的第一行......然后当您编写单元测试时可以避免编写一些更基本的测试，因为代码契约涵盖它已经..是真的吗？

合同是否适用于 WCF 调用？我猜不是，因为代理是自动与您一起创建的，您无法更改。

【问题讨论】：

我想知道这与 ASP.NET 验证器有何关系？还是这些东西只适用于 BLL？

标签： .net unit-testing .net-4.0 code-contracts

【解决方案1】：

每当我需要验证输入参数是否需要具有特定值（数字为正，对象不为空）时，我都会使用它们。

对于输出，只要我确定返回值应该处于某种状态（例如，不为空），我就会使用它们。

在代码中包含契约可确保在出现意外值的那一刻引发异常，而不是在代码中由于意外假设而导致对象意外处于损坏状态的更深层次。

就个人而言，我认为它使代码更清晰。该符号减少了编写量（而不是使用 if(....== null)....）。这种方式Contract.Requires 也是它试图完成的任务。当我看到我知道代码正在评估某个参数处于某种状态时。

【讨论】：

整体上真的可以节省您的时间吗？您认为与仅使用断言相比，您的主要优势是什么？我担心代码合同是我在我的代码中放置的东西之一，但实际上它过度杀伤并且只是使代码膨胀，因为检查非常明显。我想我仍在等待一个更好的例子'SEE？它检查字符串是否为空！'
无论如何你都应该验证你的输入。我认为它可以节省时间，因为其他程序员很容易明白你的意图是什么。您可以对 if 语句执行相同的操作，但 Contract.Requires 表明您正在验证输入。没有人猜测发生了什么。另一个很酷的事情是您可以在项目文件中定义合同的工作方式。在开发过程中，您可以将合约设置为在发生违规时立即停止程序。
代码契约在WCF中是如何实现的？是否使用导出策略。您能否提供一个参考，其中代码合同用于业务验证？
我已经有一段时间没有使用 WCF 的代码契约了，但是要获取方法和数据对象之外的任何内容，您必须从服务层导出 WCF 引用。更简单的方法是围绕 WCF 接口构建一个包装器，将您的代码协定构建到客户端应用程序中，然后客户端应用程序中的其他方法调用该包装器。

【解决方案2】：

有一个关于合同的研究领域：http://en.wikipedia.org/wiki/Design_by_contract 在.net 中引入它们之前很久。

代码契约有助于回答以下问题：

方法期望什么？
方法保证什么？
方法维护什么？

如果您可以为这些问题编写小而易读的合同，那么请使用它。

【讨论】：

所以如果一个项目开始了，Bob 做 UI，Joe 做 BLL……这种类型的设计不仅让 Bob 和 Joe 交换方法的作用和参数。但也在 UML（或其他）中定义了参数的允许值......然后你在方法顶部使用代码协定来添加这些验证......这将如何工作？
类似的东西。它只是扩展验证。有一些工具可以将联系人提取到独立文档中。

【解决方案3】：

一个使用 CodeContracts 的主要原因是让静态分析能够检测违反 CodeContracts 的行为，以便及早发现它们，而不是在运行时导致错误或未知行为。

如果您愿意，可以禁用 CodeContract 的运行时强制。

使用它们的另一个很好的理由是将合同定义添加到 XML 代码注释以增强 API 文档。这也适用于 Sandcastle，尽管需要进行一些调整才能完全集成它们。请参阅 2011 年 2 月 4 日（或更高版本）的代码合同用户手册中的第 8.3 节，地址为http://research.microsoft.com/en-us/projects/contracts/userdoc.pdf

【讨论】：