WCF/WCF 数据服务/WCF RIA 服务

Question

不要添加关于不同 WCF 堆栈的另一篇 SO 帖子，但我想在浪费更多开发时间之前确保我朝着正确的方向前进......

我的场景 - 我们公司有许多 Web 应用程序，它们都访问同一系列的数据库。所有应用程序基本上都是独立开发的，因此存在大量的业务逻辑和数据访问重复。最重要的是，我有一个(可能不合理的)目标，即使该项目独立于客户端 - 将我们当前的业务逻辑和数据访问整合到一个可由 Web 应用程序、Silverlight、移动应用程序等访问的界面中。

进入 WCF - 在我看来，它是实现这两个目标的完美选择。不幸的是，在阅读了各种 WCF 风格的所有现有“指南”后，我总是感到更加困惑。以下是我迄今为止得出的结论 - 请随时纠正我:

• Straight WCF - 最灵活、最全面的选择，但一切都从头开始；需要大量的前期时间来配置和测试；技术上最成熟的选项，带有钩子(Hook)来完成大部分目标
• WCF 数据服务 - 在线获取 REST 服务的最快方式；如果应用程序只需要直接从数据库公开数据，则非常好；如果需要业务逻辑，则必须在客户端编写或由公开该逻辑的第二个服务编写。
• WCF RIA 服务 - 配置准备公开业务逻辑的服务的最快方法；可能是技术上最不成熟的选项(但看起来需要大量投资才能实现)； Soap、REST 和 JSON 端点将允许大部分客户端独立；

因此，鉴于我的上述要求，我得出以下结论 - 由于业务逻辑要求，数据服务可能无法启动(并且使用数据服务的第二个 WCF 服务的想法让我觉得这是一个极其糟糕的架构选择);速度很重要，这表明 RIA 服务可能是最好的起点(你可以说我很懒，但拥有一个时间紧迫的小团队使得代码生成变得有值(value))。

是否有更好的方法来实现我所描述的目标？我是否误解了任何/所有 WCF 选项？关于选择哪种 WCF 方法，还可以提供哪些其他实用指导(不仅对我而言，而且对尝试评估技术的其他人也如此)？

Answer 1

我会直接选择 WCF。

这允许您根据需求通过各种端点公开您的服务:

• 用于跨平台互操作性的 SOAP
• 适用于需要速度的内部客户端的二进制 NetTcp
• 用于轻量级访问的 JSON