在现有的WCF应用程序(IIS)中托管一个ASP.net MVC 4站点
本文关键字：一个 ASP 4站点 MVC net WCF 应用程序 IIS | 更新日期: 2023-09-27 18:12:25
我的公司使用。net WCF提供了一个大规模的SOAP应用程序。在这个现有的WCF应用程序中，我们现在需要托管一个Asp.net MVC 4(或5)网站。这意味着我们需要某种路由，将特定类型的uri完全重定向到asp子组件，并将其作为单独的应用程序进行处理。
搜索这个问题，我只找到解决方案，你这样做的另一种方式——当然，在Asp MVC内部路由到WCF子组件将是非常容易和直接的。然而，这在我们的案例中是不可能的。WCF包含了很多我们不能(也绝对不想)转移到Asp组件中的安全钩子。另一方面，把它分成两个单独的应用程序，让IIS来做路由也是不可能的解决方案，因为我们的应用程序与我们公司的其他软件包有大量的依赖关系，我们不想在单独的应用程序中维护两次。
现有的WCF组件作为一个独立的web应用程序托管在IIS 7.5和。net 4.0应用程序池中。
是否有任何合理的方式从WCF到Asp.net MVC的子路由?
这种方法听起来会给你和你的公司带来更多的问题。我知道你提到把它分成两个独立的部分是不可能的，但是我认为有几个原因。
-
WCF和MVC中的身份验证和授权差异很大，我会将这些代码重构到一个不依赖于每种技术的库中，然后为每个应用程序编写WCF和MVC抽象。你得到了重用但也有两个组件理解底层技术
-
Routing WCF不理解路由，它只有一个入口点。将调用哪个方法的决策嵌入到消息的有效负载中。而MVC是基于url路由的
-
将更新部署到MVC站点将需要WCF服务更新，反之亦然
这些只是我想到的一些。这样做似乎过于复杂，而且不太好。我将考虑在IIS中单独托管两个应用程序，并将公共逻辑提取到允许重用的公共类库中。
我建议你给WCF服务和ASP。
你将会发现让WCF位于 IIS和ASP.NET之间是极其困难的(或者至少是开创性的)。它们可以并肩工作，也可以独立工作。
考虑到它是相当简单的有WCF和ASP。. NET/MVC使用相同的底层认证系统(例如Forms Auth)，你对架构正确的主要反对意见似乎是"与我们公司的其他软件包的大量依赖关系，我们不想在单独的应用程序中维护两次"。
再次解决这个问题似乎是一个相当简单的重构。您的任务将只是从业务逻辑中提取出所有WCF特定的代码，然后将业务逻辑放入单独的类库中，以便在WCF和MVC应用程序之间共享。对我来说，除了这个，没有其他明智的方法来解决你的问题。任何其他的方法可能会给你留下比你现在的WCF应用程序更混乱的东西。