Хотели бы вы, чтобы ASP.NET MVC представлял механизм, в котором представление полностью создается в коде?

Недавно я создал всплеск движка представлений, в котором представления представляют собой простые классы, а контент создается с помощью забавных usingблоки

Код вместе с простым примером сайта доступен по адресу http://code.google.com/p/sharp-view-engine/

Здесь я хотел бы услышать ваше мнение относительно такой идеи. Это совершенно странно или, может быть, кому-то это нравится?

Источник

3 ответа

Решение

Я бы на самом деле не хотел этого.

Я могу согласиться с DSL (такими как Parser-Combinator или для генерации XML-узлов в контексте данных), но в этом случае я думаю, что в коде вкладывается слишком много. И, в конце концов, это только усложняет границы и приводит к сложному в обслуживании коду. (Вы уже можете сделать то же самое, но с большей детализацией, просто используя "стандартные" веб-элементы управления. Вы всегда можете использовать {subblock} в C#, чтобы ограничить область видимости переменных.)

Подход, который я предпочитаю использовать, - это шаблоны с привязками (но без "кода в шаблонах"). Это облегчает "дизайнеру" (надеюсь, не мне или следующему человеку, который придет и) редактирование макета представления так, как они считают нужным. Однако основная логика (доступные элементы управления и привязки) хранится в коде - без помех. (Другое преимущество шаблонов заключается в том, что если они размещены снаружи, им не требуется перекомпиляция для каждого небольшого изменения.)

Простота и ремонтопригодность подобны... дзен.

Источник

Это интересная идея, доведенная до крайности, я бы сказал. В моем магазине мы используем html-соглашения практически для всего, кроме макета. Единственный реальный HTML, который мы имеем в проекте, это наша главная страница Spark. Для генерации самого контента мы используем условный механизм, который выделяет семантическую модель HTML. (Мы используем библиотеку HtmlTags из FubuMVC для построения семантической модели.)

Пример соглашения для визуализации многострочного текстового поля выглядит так:

public static HtmlTag Build(ElementRequest req)
{
    return Tags.TextArea
            .Rows(6)
            .Id(req.ElementId)
            .Attr("name", req.ElementId)
            .Text(req.StringValue());
}

Эти соглашения запускаются при отражении в модели представления (или мы можем вызвать их вручную из вспомогательного метода). Вывод выводится (через ToString()) в раздел содержимого нашей главной страницы. Мы шутим, что довольно скоро нам даже не понадобится движок просмотра.

ps вот как мы справляемся с вложенностью. (Ваши блоки использования выглядят загроможденными!)

return Tags.Div.Nest(
    Tags.Button("save").AddClass("positive"),
    Tags.Span.Text(" or "),
    Tags.Anchor.Text("cancel").AddClass("negative")
);

Nest () - это метод расширения, который просто принимает массив params из HtmlTag и добавляет их в дочернюю коллекцию родителя.

Источник

Также есть еще один чистый вид C# для ASP.NET MVC - SharpDOM - http://sharpdom.codeplex.com/ - похожая идея, но не такая загроможденная - объединяет чистый HTML и логику - оба выражены в C#

Источник
Другие вопросы по тегам