.net 将asmx Web服务临时Facading到WCF服务

我有一个应用程序，它是一个用.NET2.0编写的ASMXWeb服务，下面有一些业务逻辑和一个存储库

计划是，此web服务将作为希望保存和检索数据的应用程序的API

从长远来看，我知道当.NET2.0代码库被重构并成为.NET4代码库时，web服务可能会被WCF服务所取代

为了减少API对消费者的影响，我正在考虑放弃WCF服务作为asmx服务的门面是否是一个好主意。在重构.NET2.0代码时，这将保持不变。当没有.NET2.0代码时，asmx服务将消失，WCF服务将在没有asmx服务的情况下与业务逻辑对话

我的问题是

这将导致什么样的性能开销

---

有更好的解决方案吗？

您将为额外的服务层支付双重序列化/反序列化罚款。如果你的信息很小，这就不会那么明显了

您可能希望使用BasicHttpBinding部署同一服务的WCF版本。这样，您就可以充分利用这两个方面：

• 该服务正在使用WCF部署在一个地方（并且仍然可供遗留客户端使用）
• 如果需要更新代码，可以使用不同的绑定公开其他端点

---

编辑：当然，您可以使用基于WCF的代理将新代码连接到旧代码。只要名称保持不变，以后对服务的重构就不会太痛苦。

我将您的问题理解为“我可以从.Net 4 WCF服务引用.Net 2.0组件吗？”

此链接

---

.NET Framework 4与使用.NET Framework版本1.1、2.0、3.0和3.5构建的应用程序向后兼容。换句话说，使用以前版本的.NET Framework构建的应用程序和组件将在.NET Framework 4上运行。

感谢您的回答…我非常乐意在如果WCF服务可能与下面的.NET2代码共存（一段时间），则不使用它下面的web服务.这就是你所说的使用基于WCF的代理的意思吗？如果是的话，你能扩展一下吗，因为我不想让序列化成本翻一番。是的，基本上我说的一个选项是让旧服务保持原样，但只为它们创建WCF客户端。在Visual Studio中，你有两个选项-创建新的WCF客户端（也称为服务引用）或者旧的“Web引用”。理论上，如果您保持webMethods和类的相同，那么最终在WCF中重写服务时，您的代码就不会有机会了。非常好-因此我可以完全跳过编写Web服务，而编写一个使用.NET 2组件的WCF服务。谢谢。