ASP.net MVC — представления и лучшие практики jQuery

#javascript #jquery #asp.net-mvc

#javascript #jquery #asp.net-mvc

Вопрос:

Я пытаюсь выяснить, какова наилучшая практика использования jQuery в приложении MVC. В частности, я хотел бы знать, что мне следует делать, чтобы не загромождать все свои представления отдельными инструкциями document.ready.

В качестве примера:

У меня есть следующие представления:

/Views/Shared/_Layout.cshtml
/Views/Home/Index.cshtml
/Views/Home/_Dialog.cshtml
/Views/Home/_AnotherDialog.cshtml

У меня есть действие контроллера, которое будет отображать представление Home / Index, которое использует макет и отображает два частичных представления (или шаблоны редактора, шаблоны отображения и т.д.). Это одно действие контроллера отобразило 4 или более представлений. Каждое представление использует некоторый документ jquery.готовый код.

В настоящее время у меня есть код внизу каждого представления:

 // In Index
<script type="text/javascript">
    $(function() {
        $('#tabs').tabs()
    });
</script>

// In _Dialog
<script type="text/javascript">
    $(function() {
        $('#some-dialog').dialog( ... );
    });
</script>
  

Я знаю, что это не очень хорошая практика, потому что она уже становится неуправляемой в моем небольшом проекте. Каким рекомендациям следует следовать, когда у меня есть тонны страниц, которым нужен некоторый код инициализации jQuery / javascript, разделенный на десятки просмотров?

Ответ №1:

Вы могли бы сделать что-то вроде того, что Telerik делает со своим регистратором javascript. В принципе, сделайте этот регистратор доступным в вашей модели представления. На самом простом уровне все, что ему нужно делать, это отслеживать добавленные к нему строки:

 public class JavascriptRegistrar
{
    private StringBuilder jsBuilder_ = new StringBuilder();

    public Add(string js)
    {
        builder.Append(js).Append('n');
    }


    public string ToString()
    {
        return "<script type="text/javascript">"   jsBuilder_.ToString()   "n</script>";
    }
 }
  

Ваши частичные просмотры будут добавлены к этому при рендеринге:

 <h1>In my view!</h1>

@Model.Registrar.Add("$function() { /* ... */ }")
  

Наконец, в нижней части вашего основного представления, когда вы закончите:

 @Model.Registrar.ToString()
  

Который будет записывать весь javascript, который он собрал во время рендеринга.

Ответ №2:

Если инициализация специфична для представления, и вы точно знаете, что она не будет использоваться вне этого представления, например, для определенного поведения страницы, тогда просто оставьте ее в представлении!

Нет ничего плохого в том, чтобы иметь теги сценариев во всех ваших представлениях, если вы не реплицируете js между представлениями. Я думаю, что люди склонны неправильно понимать «разделение интересов» в этом случае и думают, что это просто означает «любой ценой держать разные языки подальше друг от друга»…это неправильно, очевидно, что если какая-либо логика / поведение инициализации страницы специфичны для страницы, то html и js по сути «касаются» друг друга, поэтому перемещение js в отдельный файл на самом деле не является «хорошей практикой», во всяком случае, это затрудняет понимание вашего кода.

Лично мне нравится открывать представление и иметь возможность видеть все js и css, характерные для этой страницы, как только я ее открываю, что делает ее приятной и читаемой. Однако, очевидно, что если код должен быть общедоступным, вам нужно удалить его из своего представления и получить в папке скриптов, где на него может ссылаться что угодно!

Редактировать

В вашем примере выше я вижу, что в вашем индексном представлении вы инициализируете свои вкладки. Это и так нормально, однако, если вы добавили вкладки где-то еще в проекте, то, возможно, было бы лучше создать свои вкладки, используя .tabs класс, а не #tabs идентификатор, а затем во внешнем js-файле инициализировать все ваши вкладки одновременно, вызвав $('.tabs') .

Комментарии:

1. Проблема, с которой я сталкиваюсь, сохраняя их все отдельно (даже если они специфичны для представления), заключается в наличии 10 или более разных обработчиков document.ready для одной страницы. Я не уверен, повлияет ли это на производительность или нет.

2. Я бы очень сомневался, что это как-либо влияет на производительность, он просто добавляет ваш код в очередь для запуска при запуске события ready, даже если было снижение производительности, на самом деле вы никогда не добавите в очередь больше нескольких, например, один для вашего макета, один для вашего представления, пару дополнительных для внешних файлов … определенно не проблема!