W jaki sposób MVC3 wybiera, który ViewEngine ma użyć, jeśli mam wiele silników w kolekcji ViewEngines?

Question

Mam niestandardowy mechanizm wyświetlania opracowany wewnętrznie. W tym samym projekcie chciałbym użyć Razor dla niektórych stron i mojego niestandardowego silnika dla niektórych stron. W jaki sposób platforma MVC wybiera silnik, którego ma używać? BTW, mój niestandardowy silnik nie wymaga żadnych szablonów, renderuje strony na podstawie metadanych z bazy danych. Dla mojego niestandardowego silnika nie chcę ustawiać żadnych plików szablonów. Spodziewam się, że powinien istnieć sposób na zmotoryzowanie danego silnika w oparciu o nazwę kontrolera i nazwę działania. Czy ta elastyczność istnieje w MVC3?

Answer 1

Twój aparat wyświetlania powinien implementować interfejs IViewEngine. Po zarejestrowaniu mechanizmu wyświetlania za pomocą metody ViewEngines.Engines.Add(), struktura MVC zadzwoni pod numer FindView i FindPartialView, gdy będzie potrzebować mechanizmu wyświetlania do renderowania widoku.

Jest absolutnie możliwe, aby silniki z wieloma widokami działały obok siebie. Jeśli nie chcesz, aby twój mechanizm wyświetlania był używany w konkretnej sytuacji, musisz return new ViewEngineResult(new string[0]); z FindView lub FindPartialView, a MVC wybierze inny mechanizm wyświetlania. Jeśli chcesz, aby twój mechanizm wyświetlania był używany, zwrócisz poprawną ViewEngineResult wskazującą na klasę widoku (która implementuje IView), która ma być wynikiem Render.

Istnieje kilka szczegółów z parametrem useCache. Jeśli chcesz dowiedzieć się więcej, była świetna prezentacja na temat budowania własnego silnika widokowego w TechEd 2011 autorstwa Louisa DeJardina. Możesz znaleźć film o Writing an ASP.NET MVC View Engine na Channel9.

Answer 2

Myślę, że najłatwiej byłoby wdrożyć IViewPageActivator, http://bradwilson.typepad.com/blog/2010/10/service-location-pt11-view-page-activator.html i http://msdn.microsoft.com/en-us/library/system.web.mvc.iviewpageactivator(v=vs.98).aspx.

Myślę, że powracająca wartość null z metody Create spowoduje, że później będzie domyślną wartością domyślną IViewPageActivator. Wstrzykujesz go do DependencyResolver, http://bradwilson.typepad.com/blog/2010/10/service-location-pt5-idependencyresolver.html.

Może być łatwiejszy w użyciu, jeśli korzystasz ze schematu wtrysku zależności jako NInject lub Unity.