Лучший способ для разработки кода JavaScript пользовательского интерфейса с ASP.NET с точки зрения повторного использования и логической инкапсуляции? - PullRequest
5 голосов
/ 15 декабря 2009

У меня проблемы с выбором правильной практики кодирования JavaScript в пользовательском интерфейсе. Поэтому я ищу более разумный способ делать вещи. Я использую jQuery с ASP.NET, и я делаю что-то вроде ниже, что кажется непрофессиональным и глупым. Программирование на JavaScript всегда было для меня загадкой. Я знаю, как это сделать, но я никогда не знал, как это сделать правильно.

$(function(){
    $('submit').click(function() {
        //behaviors, setup styles, validations, blah...
    });
});

Проблемы:

  • Дублирование кода зачастую сложнее поддерживать и использовать повторно
  • С помощью ClientIds, генерируемых ASP.NET, трудно разделить фрагменты кода на отдельные файлы js
  • Общие объявления размещаются на главных страницах, однако функция готовности документа jQuery также присутствует почти на всех других страницах

Цели:

  • Библиотека JavaScript / независима от фреймворка, так что будет проще переключать фреймворки в будущем
  • Инкапсулировать / модулировать логику для легкого повторного использования, так что на каждой странице будет только несколько простых строк кода инициализации
  • Разделение задач для удобства обслуживания и удобочитаемости

Вопросы:

Будучи разработчиком на C #, я думаю, в основном, оО, а jQuery очень процедурный. Я понимаю концепции анонимной функции, но в целом мой ум все еще пытается создать модель предметной области, которая абстрагирует UI, а затем объявляет свойства или методы. Но я действительно не уверен, так ли это в JavaScript. Или я слишком идеален, или я слишком стараюсь сделать что-то, что не должно быть похожим на OO OO? Итак, вопросы:

  • Должен ли я начать инкапсулировать / модулировать функции с использованием прототипа JavaScript и сделать его более похожим на ОО? Так что элементы управления HTML или поведения могут быть инкапсулированы для повторного использования?
  • Или я должен начать инкапсулировать логику в плагин jQuery? Но в этом случае код будет на 100% зависеть от jQuery.
  • Или любые другие подходы?

Спасибо.

Обновлено: Я только что нашел этот слайд , и это, кажется, хорошая отправная точка. Это также хороший пример , который я только что нашел. И хороший учебник от создателя jQuery.

Ответы [ 4 ]

2 голосов
/ 15 декабря 2009

Лучший метод, который я нашел для повторного использования кода, работы с идентификаторами клиентов и т. Д., - это привнести более объектно-ориентированный подход в мой Javascript.

Это имеет следующие преимущества

  1. Проще ввести область видимости и несколько экземпляров одного и того же предмета на одной странице
  2. Проще управлять идентификатором клиента фарсом

Я все еще использую Jquery в этом.

Поэтому, чтобы привести пример, если бы у меня был виджет на основе javascript, который я хотел бы использовать, я бы создал «объект» с именем widget и сохранил его в файле Widget.js. Объект виджета будет иметь переменные экземпляра, конструктор и публичные, приватные методы, как и в любом другом языке OO, например, Widget.js будет выглядеть как

// constructor
function Widget(aFooId,bBarId)  
{
 // instance variables  
 var fooId = aFooId;  
 var barId = bBarId;  

 // some magic to expose public methods  
 this.Init = Init;  

 // public methods  
 function Init()  
 {  
   alert("called init");  
 } 

 //private methods  
 function PrivateMethod()  
 {  

 }  

}  

вызов на странице aspx будет выглядеть как

var widgetInstance = new Widget("<%=Foo.ClientId%>",<%=Bar.ClientId%>);
widgetInstance.Init();
2 голосов
/ 15 декабря 2009

Проблема ClientId известна и ее трудно обойти. ASP.NET 4.0 представляет ClientIDMode, который позволит вам лучше контролировать окончательный отображаемый идентификатор. ASP.NET MVC определенно сделает вашу жизнь сценариев клиента намного проще. Если это вызывает у вас горе и ожидание, что ASP.NET 4.0 или использование ASP.NET MVC являются жизнеспособными вариантами, я бы рассмотрел эти альтернативы.

1 голос
/ 15 декабря 2009

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

Вы можете обойти проблему ClientId, используя ASP.NET 4.0 (как предлагает Кевин П), или ссылаясь на элементы, используя 'заканчивается-с' селектор, такой как

$('input[id$=_ProductName]

, который соответствует концу атрибутов идентификатора, поэтому он будет соответствовать

<span id="ctl00_MyHeader_ProductPanelPlaceholder_ProductName">

, даже если ID содержащихся элементов управления изменяются.

0 голосов
/ 15 декабря 2009

Я считаю, что веб-фреймворк LiveUI - это именно то, что вы ищете, пожалуйста, посмотрите на http://www.codeproject.com/KB/custom-controls/jquery-datepicker-aspnet.aspx

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...