不要添加另外关于不同WCF堆栈的SO帖子，但我想确保在浪费更多开发时间之前我正朝着正确的方向前进...
我的场景 - 我们公司有许多网络应用程序都可以访问同一系列的数据库 . 所有应用程序基本上都是独立开发的，因此有大量的业务逻辑和数据访问重复 . 最重要的是，我有一个（可能是不合理的）目标，即使这个项目独立于客户端 - 将我们当前的业务逻辑和数据访问整合到一个界面中，该界面可以通过Web应用程序，Silverlight，移动应用程序等进行访问 .
输入WCF - 这对我来说是完美的选择 . 不幸的是，在阅读了各种WCF风格中存在的所有现有“指导”之后，我总是比任何事情都更加困惑 . 以下是我到目前为止得出的结论 - 请随时纠正我：
-
直线WCF - 最灵活和最全面的选择，但一切都从头开始;需要大量时间来配置和测试;最技术成熟的选项，带钩子来完成大部分目标
-
WCF数据服务 - 在线获取REST服务的最快方式;如果应用程序只需要直接从数据库中公开数据，那就太棒了;如果需要业务逻辑，则必须在客户端或通过公开逻辑的第二个服务写入 .
-
WCF RIA服务 - 配置准备公开业务逻辑的服务的最快方法;可能是技术上最不成熟的选择（但看起来像是一项重要的投资来实现它）; Soap，REST和JSON endpoints 将允许大多数客户端独立性;
因此，鉴于我的上述要求，我得出以下结论 - 由于业务逻辑要求，数据服务可能不是首发（并且第二个WCF服务消费数据服务的想法让我觉得这是一个非常糟糕的架构选择）;速度很重要，这表明RIA服务可能是最好的起点（称我为懒惰，但拥有一个时间紧迫的小团队会使代码生成变得有 Value ） .
有没有更好的方法来处理我描述的目标？我是否误解了任何/所有WCF选项？关于选择哪种WCF方法可以提供哪些其他实用指导（不仅适用于我，还适用于其他任何试图评估技术的人）？
1 回答
我会选择直接的WCF .
这允许您根据要求通过各种 endpoints 公开您的服务：
SOAP用于跨平台的互操作性
二进制NetTcp，适用于需要速度的内部客户端
JSON用于轻量级访问