ASP.NET MVC: использование LINQ to XML для визуализации (X) HTML - PullRequest
Новая
       14

ASP.NET MVC: использование LINQ to XML для визуализации (X) HTML

2 голосов
/ 06 мая 2009

Было много дискуссий по поводу View-engine для ASP.NET MVC и некоторой критики против встроенного «tag-soup» с for-loop и тому подобным.

Альтернативой или дополнением было использование HTML-помощников, которые являются просто встроенными вызовами методов.

Когда я смотрю в HTML-помощники ASP.NET MVC сегодня, они используют класс под названием TagBuilder .

Мое предложение состоит в том, чтобы использовать LINQ to XML, чтобы получить строго типизированный и правильно отформатированный (X) HTML : 

XDocument output = new XDocument();
XElement root = new XElement("div",
    new XAttribute("class", "root_item"));

XElement iconImage = new XElement("img",
    new XAttribute("src", ResolveUrl("~/image.gif")),
    new XAttribute("alt", "This is an image"));

XElement link = new XElement("a",
    new XAttribute("class", "link"),
    new XAttribute("href", "http://google.com"),
    new XText("Link to Google"));


root.Add(link);
root.Add(iconImage);
output.Add(root);

Мне это нравится, потому что это похоже на строго типизированные элементы управления в WebForms, где вы можете создать новую кнопку и добавить ее в коллекцию элементов управления другого элемента управления.

Есть ли какие-либо очевидные проблемы или ограничения в этом?

Ответы [ 2 ]

3 голосов
/ 22 мая 2009

Это отличная идея! Единственная проблема, которую я вижу, это использование C #. ;) В VB.NET значительно улучшена поддержка создания XML с помощью функции XML-литералов.

Код, который вы перечислите в своем вопросе, может быть написан так в VB.NET. (С добавлением текста «Это ссылка» , поскольку в вашем примере не было текста внутри элемента a.) 

Dim root = <div class="root_item">
               <img src=<%= ResolveUrl("~/image.gif") %> alt="This is an image"/>
               <a class="link" href="http://google.com">This is a link</a>
           </div>

Есть еще <%= ... %> теги, но они проверяются на достоверность во время компиляции. Если для этого кода было возвращено значение функции, возвращающей тип XElement, этот фрагмент Xhtml можно было бы повторно использовать в другом месте сайта.

У меня есть проект на CodePlex, который использует литералы XML VB.NET в качестве пользовательского ASP.NET MVC View Engine по адресу http://vbmvc.codeplex.com. Он основан на коде Дмитрий Робсман , который является продуктом Диспетчер модулей для ASP.NET в Microsoft. Представления - это классы VB.NET, а мастер-страницы - базовые классы. Вы new-up Частичные классы представления вместо ссылки на них по имени строки, так что это также дополнительная проверка времени компиляции. Вместо класса HtmlHelper, который возвращает строки, есть класс XhtmlHelper, который возвращает XElement и работает аналогично тому, что вы предложили.

1 голос
/ 20 мая 2009

Я могу вспомнить две проблемы с вышеупомянутым методом. Во-первых, 

XElement iconImage = new XElement("img",
new XAttribute("src", ResolveUrl("~/image.gif")),
new XAttribute("alt", "This is an image"));

Ссылаясь на то, что вы пишете выше, мы можем получить что-то вроде: 

<img src=<%=whatever%> alt=<%=whatever%> />

Это может быть личное суждение или что-то подобное, но я, конечно, голосую за более позднего, более "читаемого" человека. Правильно, использование LINQ 2 XML может избавить от странных <%}%>, которые блуждают на моих страницах aspx, но в то же время вы заставляете этих "хороших мальчиков" выглядеть неуклюже.

Во-вторых, может возникнуть проблема с производительностью. Я думаю, что синтаксический анализ и выполнение LINQ 2 XML может быть довольно медленным, хотя у меня нет никаких данных по этому поводу.

Лично я все еще экспериментирую с платформой MVC, похоже, что я возвращаюсь к старым временам, таким как ASP или PHP 3.X, так как почти все интерактивные части обрабатываются явно, а не ориентированная на окна / GUI-OOP ASP Dot Net Фреймворк. Я думаю, что главная причина, по которой я буду использовать MVC, заключается в том, что он может гарантировать наилучшее качество клиентских HTML-кодов.

...