ASP.NET Core中Server.Transfer的替代 [英] Alternative to Server.Transfer in ASP.NET Core
问题描述
我正在将ASP.NET应用程序迁移到ASP.NET Core,并且他们对 HttpServerUtility.Transfer(字符串路径)
。但是, HttpServerUtility
在ASP.NET Core中不存在。
I am migrating an ASP.NET application to ASP.NET Core and they have some calls to HttpServerUtility.Transfer(string path)
. However, HttpServerUtility
does not exist in ASP.NET Core.
我可以使用其他替代方法吗?或者是 Response.Redirect
是我唯一的选择?
Is there an alternative that I can use? Or is Response.Redirect
the only option I have?
我希望尽可能保持与旧应用程序相同的行为,因为 Server.Transfer和Response.Redirect 。
I want to maintain the same behaviour as the old application as much as possible since there is a difference in between Server.Transfer and Response.Redirect.
推荐答案
我会根据您的情况为您提供一些选择:
I see some options for you, depending on your case:
- 返回其他视图:因此, HTML。请参见Muqeet Khan的答案
- 返回同一控制器的另一种方法:这还允许执行其他操作的业务逻辑。只需编写类似
return MyOtherAction( foo, bar)
之类的东西。 - 返回另一个控制器的操作:请参阅Ron C的答案。由于此解决方案忽略了整个中间件,该中间件包含了大约90%的ASP.NET Core逻辑(如安全性,Cookie,压缩,...等),因此我对该解决方案感到有点麻烦。 )。
- 路由样式中间件:添加类似于路由功能的中间件。在这种情况下,您需要在此处评估决策逻辑。
- 最后重新运行中间件堆栈:本质上,您需要重新运行很大一部分堆栈。我相信有可能,但尚未找到解决方案。我看过Damian Edwards(ASP.NET Core的PM)的演讲,他托管了没有使用Kestrel / TCPIP的ASP.NET Core,仅用于在浏览器中本地呈现HTML。那你可以做。但这是一个很大的负担。
- Returning another View: So just the HTML. See answer of Muqeet Khan
- Returning another method of the same controller: This allows also the execution of the business logic of the other action. Just write something like
return MyOtherAction("foo", "bar")
. - Returning an action of another controller: See the answer of Ron C. I am a bit in troubles with this solution since it omits the whole middleware which contains like 90% of the logic of ASP.NET Core (like security, cookies, compression, ...).
- Routing style middleware: Adding a middleware similar to what routing does. In this case your decision logic needs to be evaluated there.
- Late re-running of the middleware stack: You essentially need to re-run a big part of the stack. I believe it is possible, but have not seen a solution yet. I have seen a presentation of Damian Edwards (PM for ASP.NET Core) where he hosted ASP.NET Core without Kestrel/TCPIP usage just for rendering HTML locally in a browser. That you could do. But that is a lot of overload.
一个忠告:转移已死;)。这样的差异是ASP.NET Core存在和性能提高的原因。这对迁移不利,但对整个平台有利。
A word of advice: Transfer is dead ;). Differences like that is the reason for ASP.NET Core existence and performance improvements. That is bad for migration but good for the overall platform.
这篇关于ASP.NET Core中Server.Transfer的替代的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!