在本文中，我将阐述使用实体框架（通过 Windows Communication Foundation (WCF) RESTful 服务公开 并用 Windows Azure 访问控制服务 (ACS) 保证安全），实施开放数据协议 (OData)。
如同大多数开 发人员，我经常发现自己试图利用各种新方法综合利用多种技术，以便尽可能高效地完成项目，同时还要提供 一种灵活、易于维护的解决方案。这样做可能很困难，当项目需要快速安全地公开数据时尤其如此。
最近我需要为一个现有数据库和 Web 应用程序创建一个安全的 Web 服务。我真的不想实施代码的所有 CRUD （创建、读取、更新、删除）操作。仅仅创建自定义服务约定、操作约定和数据约定就非常诱人，这样可以准 确实现如何公开数据，以及其他人如何通过服务使用这些数据。但是我知道必须采取一种更为有利的办法。我 开始研究完成这项工作的各种方法，并看到 OData （我喜欢称其为“哦数据”）的潜力。问题在于 OData 本 身并不安全，这是我不能接受的，所以我需要在 OData 服务之上添加一个安全层，这样我才放心 OData 是有 安全保障的。当我开始着手之时，我发现了 ACS，ACS 非常适于实施基于云的联合身份验证和授权服务，这正 是我需要的。然后我觉得很得意。我意识到如果我将 ACS 与 OData 结合起来，我就得到解决方案了。
现在，我的确考虑实施自定义服务约定，实施这种方法是可行的，尤其是当数据模型前面需要一个抽 象层以及需要保护数据库实体以防直接向服务消费者公开的情况下。然而，鉴于其非常耗时——创建关于如何 使用此服务的适当文档，以及投入额外的努力以设置安全性（“MessageCredential”和 “TransportWithMessageCredentials”），所以这个项目可能会很快失控。我还担心为了支持如何使用这些 服务而因为这样或那样的原因需要或请求额外的方法，这样会再次增加时间、维护和自定义。即使服务的实施 直接使用了实体框架与 ADO.NET，仍然可能需要进行代码的所有 CRUD，以便保持数据层的同步。假设有几十 个表，这种工作可能非常单调乏味。而且，创建并维护任何附加的文档和实施详情以便让最终用户使用我的服 务，只会让这项工作变成一个更加复杂的主张，难以管理。
更简便的方法
我确认了主要技术之 后，我开始寻找其他技术来填补空缺并帮助构建一套结合紧密的解决方案。目标是限制需要编写或维护的代码 数量，同时安全地公开我的 OData WCF RESTful 服务。我结合的技术是： ACS、OData、实体数据模型、WCF 数据服务（具有实体许可）及一个自定义 Windows Azure 安全实施。每项技术都具有各自的重要价值，但结 合起来，他们的价值将大幅增加。图 1 大体显示了部分技术的工作原理概述。
图 1 具备安全性截获的 ACS 简要概述
在试图合并所有这些技术之前，我必须回头，仔细了解每种技术以 及这些技术会对本项目有什么影响。然后我清晰地掌握如何整合这些技术，以及其他人通过其他技术来使用我 的服务还需要哪些条件。