Шаблоны jQuery и частичные представления в ASP.NET MVC

Я смотрю на шаблоны jQuery. Выглядит очень интересно — простой синтаксис, простой в использовании, очень чистый.

Тем не менее, я действительно не понимаю, почему лучше использовать шаблоны jQuery, а не просто получать частичные представления через AJAX. Просто кажется, что частичные представления намного проще поддерживать, и это помогает избежать дублирования кода.

Я хочу использовать шаблоны jQuery. Но когда это лучше, чем частичные просмотры?


jquery asp.net-mvc jquery-templates
person Jaco Pretorius    schedule 13.02.2011    source источник
comment
Я хочу использовать шаблоны jQuery — почему?   -  person bzlm    schedule 13.02.2011
comment
@bzlm: Все дело в шумихе ;-)   -  person Adrian Grigore    schedule 13.02.2011
comment
@ Адриан Да, может быть. :) @Jaco Что касается простого синтаксиса в вашем вопросе, я позволю себе не согласиться. Весь материал {{}} — это еще один синтаксис представления, который нужно изучить. Если вы уже используете ASP.NET MVC, шаблон jQuery просто замедлит работу.   -  person bzlm    schedule 13.02.2011

Ответы (3)


arrow_upward
11
arrow_downward

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

Преимущества частичного просмотра:

  • Типобезопасность (при использовании строго типизированных моделей представления)
  • Разрешает статический синтаксис и проверку типов.
  • Полная поддержка автозавершения кода/подсветки синтаксиса в Visual Studio

Преимущества шаблонов jQuery:

  • Позволяет обновлять страницу перед выполнением обратных передач или вообще без каких-либо обратных передач на сторону сервера. Это может быть удобно при создании интерфейсов с большим количеством ajax, возможно, также с автономными возможностями на основе html5.
  • Вы можете получать данные с сервера в формате JSON и отображать их в HTML. JSON намного короче форматирования HTML, поэтому это может повлиять на время загрузки страниц для длинных списков записей данных при использовании медленного интернет-соединения.

Таким образом, по сути, частичные представления более стабильны, а шаблоны jquery (для веб-сайтов ajax) более эффективны. Поэтому я использую частичные представления для менее посещаемых веб-страниц, которые необходимо быстро разрабатывать, и шаблоны jQuery для веб-страниц с большим количеством ajax, где производительность действительно имеет значение.

person Adrian Grigore    schedule 13.02.2011
comment
Я надеялся, что смогу привести более убедительные аргументы в пользу шаблонов jQuery, но, думаю, это лучшее, что мы можем сделать. Спасибо, Адриан. - person Jaco Pretorius; 14.02.2011
comment
@Jaco Pretorius: Не поймите меня неправильно — шаблоны jQuery действительно отличный плагин, и я регулярно им пользуюсь. Просто я предпочитаю серверную технологию из-за ее простоты использования и стабильности, если только у меня нет веских причин использовать более тяжелое клиентское решение. Я предполагаю, что есть люди, которые на самом деле чувствуют себя более комфортно, используя Javascript, чем Razor / C#, и для них шаблоны jQuery — это путь. Ни один не плохой выбор ИМО. - person Adrian Grigore; 14.02.2011
comment
Кроме того: шаблоны jQuery отлично работают с KnockoutJS. Попробуйте, если вы еще этого не сделали, это действительно здорово. - person Anders Fjeldstad; 30.06.2011
comment
@Anders: Это действительно аккуратно, но, как я уже говорил, я действительно предпочитаю более ориентированный на сервер подход. Это не так гладко, но более надежно, по моему опыту. - person Adrian Grigore; 01.07.2011
comment
@Adrian У вас был негативный опыт использования шаблонов jQuery с точки зрения надежности? Было бы интересно послушать. - person Anders Fjeldstad; 01.07.2011
comment
@Anders: Вовсе нет, но у меня было много негативного опыта в отношении надежности javascript в целом. Но это только я и YMMV. - person Adrian Grigore; 01.07.2011

arrow_upward
3
arrow_downward

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

person Dave Ward    schedule 13.02.2011
comment
Но вы также можете сделать то же самое, загрузив частичное представление, которое показывает только одну строку, и вставив его в DOM. $.load(...) делает именно это. - person Adrian Grigore; 13.02.2011
comment
Не совсем. Во многих приложениях может потребоваться предоставить пользователю возможности редактирования в реальном времени путем мгновенного добавления шаблонных строк на стороне клиента. Не было бы веских причин блокировать рабочий процесс пользователя с задержками между клиентом и сервером в том случае, когда добавления можно было бы сохранить в фоновом режиме или позже как группу. Когда вы полностью зависите от сервера для создания разметки, вы накладываете ненужные ограничения на уровень интерактивности, которого может достичь ваше приложение. - person Dave Ward; 13.02.2011
comment
Я понимаю, что вы имеете в виду, и это действительно оптимальная реализация с точки зрения производительности, но цена за это заключается в том, что вам приходится иметь дело и синхронизировать хранилище данных на стороне сервера и на стороне клиента. Это означает более сложную реализацию и, в конечном итоге, большее количество javascript, который может легко сломаться и, следовательно, его труднее рефакторировать, чем код на стороне сервера. Это единственный способ, если вы пишете веб-приложение с автономными возможностями, но для обычного веб-сайта я бы предпочел более простое решение. - person Adrian Grigore; 14.02.2011
comment
Я использую шаблоны на стороне клиента в течение многих лет и никогда не сталкивался с подобным. Наоборот, использование JavaScript для кода пользовательского интерфейса значительно упростило большинство внутренних приложений, над которыми я работал, где поддержка JavaScript может быть обязательной. Вы не только предлагаете пользователям лучшую производительность и более высокий уровень интерактивности, но и повышаете продуктивность разработчиков. По моему опыту, эти выгоды намного перевешивают любые потери в производительности рефакторинга. - person Dave Ward; 14.02.2011

arrow_upward
2
arrow_downward

я бы добавил, что одним из преимуществ jqt является то, что вы можете очень легко передать разработку внешнего интерфейса третьей стороне (которая специализируется на этом типе работы), и им нужно только знать объектную модель json. (плюс, возможно, несколько «интерфейсов» обратно на сервер)

таким образом, ваши «бэкэнд» разработчики могут сосредоточиться на поставленной задаче, а «внешняя» команда может разработать jqt. Другим преимуществом jqt является то, что они полностью изолированы от среды .net, поэтому возможно (хотя и маловероятно), что внутренняя технология может быть изменена (j2ee, php и т. д.) для подмножества действий без внешнего интерфейса, заботящегося за пределами адрес отдыха.

это интересное «пространство» для наблюдения, с которым я только начинаю баловаться. однако по обе стороны баррикад ситуация будет только улучшаться, и, как я уже говорил Дейву (Уорду) несколько недель назад, возможно, некоторые конечные точки движка бритвы предложат способ непосредственной интеграции с jqt в будущих версиях — вроде как неизбежный.

person jim tollan    schedule 13.02.2011
comment
Если такой забор существует, я предлагаю его снести. :) - person bzlm; 13.02.2011
comment
Взгляните на блазор. вы используете razor и C# для создания одностраничных веб-приложений на клиенте.blogs.msdn.microsoft.com/webdev/2018/02/06/ - person Harry; 13.03.2018