Как реализовать настраиваемый механизм просмотра в ASP.Net MVC, который (sorta) не основан на файлах?

Question

Я создал довольно общий view engine, который я создал изначально, не нацеливаясь на ASP.Net MVC. Теперь, хотя, я думаю, было бы неплохо иметь его там, где его можно, по крайней мере, легко использовать в проектах MVC. Мне интересно, будет ли мой проект хорошо отображаться в стиле ASP.Net MVC.

Проблема, с которой я сталкиваюсь, заключается в том, что мой механизм просмотра генерирует все во время компиляции с помощью шаблонов T4. Это означает, что все статически типизировано по большей части. Однако большая часть MVC немного набрана.

Так что для какой-то точки зрения вы могли бы этот код, генерируемый:

class MyView{ 
    public string Foo{get;set;} 
    public int Bar{get;set;} 
    public string Render(){ 
    return "This is my view: "+Foo+(string)Bar; 
    } 
} 

И из-за того, как это работает, даже если есть мнения/FooView.html файл, он может обрабатываться в класс с именем MyView ,

Как наилучшим образом назначить ViewData сказать Foo и Bar MyView? Должен ли я просто наложить ограничение, что вы можете использовать только одно поле в представлениях (в основном это ViewData) или?

Другая серьезная проблема, которую я вижу, заключается в том, что MVC почти полностью основан на файлах. Когда вы скажете RenderView("MyView",data);, он будет искать в/views/для файла с именем MyView.aspx или как угодно (вы можете изменить его внешний вид и расширение файла, конечно). Проблема в том, что MyView мог быть скомпилирован из файла с именем FooView.html. Должен ли я просто генерировать огромный список для каждого вида, доступного с их сопоставлениями от имени класса до имени файловой системы? Или есть лучший способ?

Примечание: поскольку я генерирую все представления (и, возможно, сгенерировал механизм просмотра MVC) из шаблона T4, это означает, что я мог бы писать огромные списки и другие крайне утомительные или плохие коды. Но я чувствую, что в этом случае есть лучший способ, чем огромный список, и что будут проблемы, связанные с сохранением списка.

Answer 1

Вы можете расширить свой механизм просмотра на основе T4, чтобы создать свой файл класса из вашей модели, скомпилировать его в памяти и кешировать его и передать свою модель представления в скомпилированную сборку через отражение.

http://mvct4viewengine.codeplex.com/