Jak symulować Server.Transfer w ASP.NET MVC?

W ASP.NET MVC można dość łatwo zwrócić ActionResult przekierowania:

 return RedirectToAction("Index");

 or

 return RedirectToRoute(new { controller = "home", version = Math.Random() * 10 });

To faktycznie da przekierowanie HTTP, które zwykle jest w porządku. Jednak podczas korzystania z Google Analytics powoduje to duże problemy, ponieważ oryginalny odnośnik jest zagubiony, więc Google nie wie, skąd pochodzisz. Spowoduje to utratę przydatnych informacji, takich jak terminy wyszukiwarek.

Na marginesie, ta metoda ma tę zaletę, że usuwa wszelkie parametry, które mogły pochodzić z kampanii, ale nadal pozwala mi przechwytywać je po stronie serwera. Pozostawienie ich w ciągu zapytania powoduje, że ludzie tworzą zakładki, twitter lub blogują łącze, którego nie powinni. Widziałem to kilka razy, gdy ludzie umieszczali na Twitterze linki do naszej witryny zawierające identyfikatory kampanii.

W każdym razie piszę kontroler „bramy” dla wszystkich przychodzących wizyt w witrynie, które mogę przekierować w inne miejsca lub alternatywne wersje.

Na razie bardziej zależy mi na Google (niż na przypadkowym dodawaniu zakładek) i chcę móc wysłać kogoś, kto odwiedziłby /stronę, którą dostałby, gdyby przeszła /home/7, czyli wersję 7 strony domowej.

Tak jak powiedziałem wcześniej, jeśli to zrobię, stracę zdolność Google do analizowania osoby odsyłającej:

 return RedirectToAction(new { controller = "home", version = 7 });

To, czego naprawdę chcę, to plik

 return ServerTransferAction(new { controller = "home", version = 7 });

co da mi ten widok bez przekierowania po stronie klienta. Nie sądzę jednak, żeby coś takiego istniało.

Obecnie najlepszą rzeczą, jaką mogę wymyślić, jest skopiowanie całej logiki kontrolera HomeController.Index(..)w mojej GatewayController.Indexakcji. Oznacza to, musiałem przenieść 'Views/Home'się 'Shared'więc było dostępne. Musi być lepszy sposób ?? ..

A co z klasą TransferResult? (na podstawie odpowiedzi Stansa )

/// <summary>
/// Transfers execution to the supplied url.
/// </summary>
public class TransferResult : ActionResult
{
    public string Url { get; private set; }

    public TransferResult(string url)
    {
        this.Url = url;
    }

    public override void ExecuteResult(ControllerContext context)
    {
        if (context == null)
            throw new ArgumentNullException("context");

        var httpContext = HttpContext.Current;

        // MVC 3 running on IIS 7+
        if (HttpRuntime.UsingIntegratedPipeline)
        {
            httpContext.Server.TransferRequest(this.Url, true);
        }
        else
        {
            // Pre MVC 3
            httpContext.RewritePath(this.Url, false);

            IHttpHandler httpHandler = new MvcHttpHandler();
            httpHandler.ProcessRequest(httpContext);
        }
    }
}

Zaktualizowano: Teraz działa z MVC3 (używając kodu z postu Simona ). to powinno (nie udało się go przetestować) również prace w MVC2 patrząc, czy nie jest uruchomiony w ramach zintegrowanego rurociągu IIS7 +.

Dla pełnej przejrzystości; W naszym środowisku produkcyjnym nigdy nie używaliśmy bezpośrednio TransferResult. Używamy TransferToRouteResult, który z kolei wywołuje wykonanie TransferResult. Oto, co faktycznie działa na moich serwerach produkcyjnych.

public class TransferToRouteResult : ActionResult
{
    public string RouteName { get;set; }
    public RouteValueDictionary RouteValues { get; set; }

    public TransferToRouteResult(RouteValueDictionary routeValues)
        : this(null, routeValues)
    {
    }

    public TransferToRouteResult(string routeName, RouteValueDictionary routeValues)
    {
        this.RouteName = routeName ?? string.Empty;
        this.RouteValues = routeValues ?? new RouteValueDictionary();
    }

    public override void ExecuteResult(ControllerContext context)
    {
        if (context == null)
            throw new ArgumentNullException("context");

        var urlHelper = new UrlHelper(context.RequestContext);
        var url = urlHelper.RouteUrl(this.RouteName, this.RouteValues);

        var actualResult = new TransferResult(url);
        actualResult.ExecuteResult(context);
    }
}

A jeśli używasz T4MVC (jeśli nie ... zrób!), To rozszerzenie może się przydać.

public static class ControllerExtensions
{
    public static TransferToRouteResult TransferToAction(this Controller controller, ActionResult result)
    {
        return new TransferToRouteResult(result.GetRouteValueDictionary());
    }
}

Używając tego małego klejnotu, możesz to zrobić

// in an action method
TransferToAction(MVC.Error.Index());

Edycja: zaktualizowano w celu zapewnienia zgodności z ASP.NET MVC 3

Zakładając, że używasz IIS7, wydaje się, że następująca modyfikacja działa dla ASP.NET MVC 3. Dzięki @nitin i @andy za wskazanie, że oryginalny kod nie działa.

Edycja 11.04.2011: TempData zrywa z Server.TransferRequest od MVC 3 RTM

Zmodyfikowano poniższy kod, aby zgłosić wyjątek - ale obecnie nie ma innego rozwiązania.

Oto moja modyfikacja oparta na zmodyfikowanej wersji oryginalnego postu Stana Markusa. Dodałem dodatkowy konstruktor, aby wziąć słownik wartości trasy - i zmieniłem jego nazwę na MVCTransferResult, aby uniknąć nieporozumień, że może to być po prostu przekierowanie.

Teraz mogę wykonać następujące czynności dla przekierowania:

return new MVCTransferResult(new {controller = "home", action = "something" });

Moja zmodyfikowana klasa:

public class MVCTransferResult : RedirectResult
{
    public MVCTransferResult(string url)
        : base(url)
    {
    }

    public MVCTransferResult(object routeValues):base(GetRouteURL(routeValues))
    {
    }

    private static string GetRouteURL(object routeValues)
    {
        UrlHelper url = new UrlHelper(new RequestContext(new HttpContextWrapper(HttpContext.Current), new RouteData()), RouteTable.Routes);
        return url.RouteUrl(routeValues);
    }

    public override void ExecuteResult(ControllerContext context)
    {
        var httpContext = HttpContext.Current;

        // ASP.NET MVC 3.0
        if (context.Controller.TempData != null && 
            context.Controller.TempData.Count() > 0)
        {
            throw new ApplicationException("TempData won't work with Server.TransferRequest!");
        }

        httpContext.Server.TransferRequest(Url, true); // change to false to pass query string parameters if you have already processed them

        // ASP.NET MVC 2.0
        //httpContext.RewritePath(Url, false);
        //IHttpHandler httpHandler = new MvcHttpHandler();
        //httpHandler.ProcessRequest(HttpContext.Current);
    }
}

Zamiast tego można użyć Server.TransferRequest w usługach IIS7 +.

Niedawno dowiedziałem się, że ASP.NET MVC nie obsługuje Server.Transfer (), więc stworzyłem metodę stub (zainspirowaną Default.aspx.cs).

    private void Transfer(string url)
    {
        // Create URI builder
        var uriBuilder = new UriBuilder(Request.Url.Scheme, Request.Url.Host, Request.Url.Port, Request.ApplicationPath);
        // Add destination URI
        uriBuilder.Path += url;
        // Because UriBuilder escapes URI decode before passing as an argument
        string path = Server.UrlDecode(uriBuilder.Uri.PathAndQuery);
        // Rewrite path
        HttpContext.Current.RewritePath(path, false);
        IHttpHandler httpHandler = new MvcHttpHandler();
        // Process request
        httpHandler.ProcessRequest(HttpContext.Current);
    }

Czy nie mógłbyś po prostu utworzyć instancji kontrolera, do którego chcesz przekierować, wywołać żądaną metodę akcji, a następnie zwrócić wynik? Coś jak:

 HomeController controller = new HomeController();
 return controller.Index();

Chciałem przekierować bieżące żądanie do innego kontrolera / akcji, zachowując dokładnie taką samą ścieżkę wykonania, jak w przypadku żądania tego drugiego kontrolera / akcji. W moim przypadku Server.Request nie działałby, ponieważ chciałem dodać więcej danych. W rzeczywistości jest to odpowiednik bieżącego programu obsługi wykonującego inny protokół HTTP GET / POST, a następnie przesyłającego wyniki strumieniowo do klienta. Jestem pewien, że będą lepsze sposoby na osiągnięcie tego, ale oto, co działa w moim przypadku:

RouteData routeData = new RouteData();
routeData.Values.Add("controller", "Public");
routeData.Values.Add("action", "ErrorInternal");
routeData.Values.Add("Exception", filterContext.Exception);

var context = new HttpContextWrapper(System.Web.HttpContext.Current);
var request = new RequestContext(context, routeData);

IController controller = ControllerBuilder.Current.GetControllerFactory().CreateController(filterContext.RequestContext, "Public");
controller.Execute(request);

Twoje przypuszczenie jest słuszne: umieściłem ten kod

public class RedirectOnErrorAttribute : ActionFilterAttribute, IExceptionFilter

i używam go do wyświetlania błędów programistom, podczas gdy w środowisku produkcyjnym będzie używać zwykłego przekierowania. Zauważ, że nie chciałem używać sesji ASP.NET, bazy danych ani innych sposobów przekazywania danych wyjątków między żądaniami.

Zamiast symulować transferu serwera, MVC jest nadal w stanie faktycznie robi Server.TransferRequest :

public ActionResult Whatever()
{
    string url = //...
    Request.RequestContext.HttpContext.Server.TransferRequest(url);
    return Content("success");//Doesn't actually get returned
}

Po prostu uruchom drugi kontroler i wykonaj jego metodę akcji.

Możesz utworzyć nowy kontroler i wywołać metodę akcji zwracającą wynik. Będzie to jednak wymagało umieszczenia widoku w folderze udostępnionym.

Nie jestem pewien, czy to właśnie miałeś na myśli mówiąc o duplikacie, ale:

return new HomeController().Index();

Edytować

Inną opcją może być utworzenie własnej fabryki ControllerFactory, w ten sposób można określić, który kontroler ma zostać utworzony.

Czy routing nie zajmuje się tylko tym scenariuszem? tj. dla scenariusza opisanego powyżej, możesz po prostu utworzyć procedurę obsługi trasy, która zaimplementowała tę logikę.

Dla każdego, kto używa routingu opartego na wyrażeniach i używa tylko powyższej klasy TransferResult, oto metoda rozszerzenia kontrolera, która załatwia sprawę i zachowuje TempData. Nie ma potrzeby TransferToRouteResult.

public static ActionResult TransferRequest<T>(this Controller controller, Expression<Action<T>> action)
    where T : Controller
{
     controller.TempData.Keep();
     controller.TempData.Save(controller.ControllerContext, controller.TempDataProvider);
     var url = LinkBuilder.BuildUrlFromExpression(controller.Request.RequestContext, RouteTable.Routes, action);
     return new TransferResult(url);
}

Server.TransferRequestjest całkowicie niepotrzebne w MVC . Jest to przestarzała funkcja, która była konieczna tylko w ASP.NET, ponieważ żądanie przyszło bezpośrednio do strony i musiał istnieć sposób na przesłanie żądania na inną stronę. Nowoczesne wersje ASP.NET (w tym MVC) mają infrastrukturę routingu, którą można dostosować w celu kierowania bezpośrednio do żądanego zasobu. Nie ma sensu pozwalać, aby żądanie dotarło do kontrolera tylko po to, aby przesłać je do innego kontrolera, gdy możesz po prostu skierować żądanie bezpośrednio do kontrolera i żądanej akcji.

Co więcej, ponieważ odpowiadasz na pierwotne żądanie, nie ma potrzeby wkładania czegokolwiek do TempDatalub innego magazynu tylko po to, aby skierować żądanie we właściwe miejsce. Zamiast tego dochodzisz do akcji kontrolera z nienaruszonym pierwotnym żądaniem. Możesz również mieć pewność, że Google zaakceptuje to podejście, ponieważ dzieje się to całkowicie po stronie serwera.

Chociaż możesz zrobić sporo z obu IRouteConstrainti IRouteHandler, najpotężniejszym punktem rozszerzenia dla routingu jest RouteBasepodklasa. Tę klasę można rozszerzyć, aby zapewniała zarówno trasy przychodzące, jak i generowanie wychodzących adresów URL, co sprawia, że ​​jest to punkt kompleksowej obsługi wszystkiego, co ma związek z adresem URL i akcją wykonywaną przez URL.

Tak więc, aby podążać za drugim przykładem, aby dostać się z /do /home/7, potrzebujesz po prostu trasy, która dodaje odpowiednie wartości trasy.

public class RouteConfig
{
    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        // Routes directy to `/home/7`
        routes.MapRoute(
            name: "Home7",
            url: "",
            defaults: new { controller = "Home", action = "Index", version = 7 }
        );

        routes.MapRoute(
            name: "Default",
            url: "{controller}/{action}/{id}",
            defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
        );
    }
}

Ale wracając do pierwotnego przykładu, w którym masz losową stronę, jest to bardziej złożone, ponieważ parametry trasy nie mogą się zmieniać w czasie wykonywania. Więc można to zrobić z RouteBasepodklasą w następujący sposób.

public class RandomHomePageRoute : RouteBase
{
    private Random random = new Random();

    public override RouteData GetRouteData(HttpContextBase httpContext)
    {
        RouteData result = null;

        // Only handle the home page route
        if (httpContext.Request.Path == "/")
        {
            result = new RouteData(this, new MvcRouteHandler());

            result.Values["controller"] = "Home";
            result.Values["action"] = "Index";
            result.Values["version"] = random.Next(10) + 1; // Picks a random number from 1 to 10
        }

        // If this isn't the home page route, this should return null
        // which instructs routing to try the next route in the route table.
        return result;
    }

    public override VirtualPathData GetVirtualPath(RequestContext requestContext, RouteValueDictionary values)
    {
        var controller = Convert.ToString(values["controller"]);
        var action = Convert.ToString(values["action"]);

        if (controller.Equals("Home", StringComparison.OrdinalIgnoreCase) &&
            action.Equals("Index", StringComparison.OrdinalIgnoreCase))
        {
            // Route to the Home page URL
            return new VirtualPathData(this, "");
        }

        return null;
    }
}

Które można zarejestrować w routingu, na przykład:

public class RouteConfig
{
    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

        // Routes to /home/{version} where version is randomly from 1-10
        routes.Add(new RandomHomePageRoute());

        routes.MapRoute(
            name: "Default",
            url: "{controller}/{action}/{id}",
            defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
        );
    }
}

Zauważ, że w powyższym przykładzie sensowne może być również przechowywanie pliku cookie rejestrującego wersję strony głównej, na którą wszedł użytkownik, aby po powrocie otrzymali tę samą wersję strony głównej.

Należy również zauważyć, że przy użyciu tego podejścia można dostosować routing, aby uwzględnić parametry ciągu zapytania (domyślnie całkowicie je ignoruje) i odpowiednio skierować do odpowiedniej akcji kontrolera.

Dodatkowe przykłady

• https://stackoverflow.com/a/31958586
• https://stackoverflow.com/a/36774498
• https://stackoverflow.com/a/36168395

Nie jest to odpowiedź sama w sobie, ale oczywiście wymaganie polegałoby nie tylko na tym, aby rzeczywista nawigacja „wykonywała” równoważną funkcjonalność Webforms Server.Transfer (), ale także aby to wszystko było w pełni obsługiwane w ramach testów jednostkowych.

Dlatego ServerTransferResult powinien "wyglądać" jak RedirectToRouteResult i być możliwie jak najbardziej podobny pod względem hierarchii klas.

Myślę o zrobieniu tego, patrząc na Reflector i robiąc wszystko, co robią klasa RedirectToRouteResult, a także różne metody klasy bazowej kontrolera, a następnie „dodając” to drugie do kontrolera za pomocą metod rozszerzających. Może mogłyby to być metody statyczne w tej samej klasie, dla ułatwienia / lenistwa w pobieraniu?

Jeśli się do tego zabiorę, opublikuję to, w przeciwnym razie może ktoś inny mnie pobije!

Osiągnąłem to, wykorzystując Html.RenderActionpomocnika w widoku:

@{
    string action = ViewBag.ActionName;
    string controller = ViewBag.ControllerName;
    object routeValues = ViewBag.RouteValues;
    Html.RenderAction(action, controller, routeValues);
}

A w moim kontrolerze:

public ActionResult MyAction(....)
{
    var routeValues = HttpContext.Request.RequestContext.RouteData.Values;    
    ViewBag.ActionName = "myaction";
    ViewBag.ControllerName = "mycontroller";
    ViewBag.RouteValues = routeValues;    
    return PartialView("_AjaxRedirect");
}