ASP.NET Core 中 Server.Transfer 的替代方案 [英] Alternative to Server.Transfer in ASP.NET Core
问题描述
我正在将一个 ASP.NET 应用程序迁移到 ASP.NET Core，他们有一些对 HttpServerUtility.Transfer(string path).但是，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(如安全性、cookies、压缩等).
- 路由风格中间件:添加一个类似于路由的中间件.在这种情况下，您的决策逻辑需要在那里进行评估.
- 中间件堆栈的后期重新运行:您基本上需要重新运行堆栈的很大一部分.我相信这是可能的，但还没有看到解决方案.我看过 Damian Edwards(ASP.NET Core 的 PM)的演示，他在那里托管了 ASP.NET Core，没有使用 Kestrel/TCPIP，只是为了在浏览器中本地渲染 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屋！
