Архитектура javascript приложений

[amigo*]

Здравствуйте. Недавно посмотрел презентацию Scalable JavaScript Application Architecture. Тема очень заинтересовала.

Часто приходится писать некий javascript код ("костыли") под уже готовый сайт . Иногда это небольшие фрагменты, но бывает, что количество кода сильно разрастается. Поэтому хотелость бы узнать какие существуют методы/способы построения архитектуры javascript приложений. Хотелось бы весь этот код грамотно структурировать...

Может кто-нибудь подсказать где можно ещё найти инфы по данной тематике, т.е. по архитектуре построения приложений на javascript.

[x-yuri]

интересно, как та презентация связана с масштабируемостью... что же касается архитектуры, она важна в сложных, постоянно меняющихся проектах, над которыми работает не один программист. В большинстве же случаев достаточно не писать код как прийдется: не связывать компоненты между собой без необходимости; использовать "классы"; задумываться над тем, что этот код надо будет потом править, отделять вид от представления; выделять (extract) компоненты и т.д. Здесь, скорее всего в тему будет Рефакторинг Фаулера

Под классами имеется в виду нечто подобное, если что:

function MyClass(){ ... }
MyClass.prototype.method = function(){ ... };

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

В качетсве вступления к паттернам могу порекомендовать вот эту книгу. Она не столько описывается сами паттерны, сколько рассказывает, каких их самому придумывать, по каким принципам они устроены. Правда значимость паттернов в книге имхо несколько переоценена. Хм, даже ссылку на русском нашел

и еще вспоминается БЭМ, хотя это уже по поводу верстки. Вот только для каких проектов оно имеет смысл - я хз, но для яндекс - определенно имеет

[B@rmaley.e><e]

Про паттерны и JS можно почитать в JavaScript Patterns.

[amigo*]

Спасибо за развёрнутый ответ. Использую классы, стараюсь применять, где это действительно необходимо, observer паттерн. Так же при изменинии интерфейса (html кода) реализую что-то типа MVC паттерна. Т.е. есть "модель" она же subject и есть представление - это части html интерфеса. И при возникновении событий в элементах эти события передаются в "модель".
В архитектуре, которая меня заинтересовала (по указанной выше ссылке) понравилась идея модулей и песочницы.
Спасибо за предоставленные ссылки.

[lenok_sm]

Здравствуйте.
Тоже интерисуюсь этим вопросом, но немного по другой части. При таком способе построения архитектуры многие классы предстают в виде js-модулей. Т.е само понятие "класс" пропадает ( особенно, если в дополнение использовать, например, blackbone.js ).
Вопрос: как можно это показать на диаграммах (например, UML)

[lenok_sm]

up

[monolithed]

При таком способе построения архитектуры многие классы предстают в виде js-модулей. Т.е само понятие "класс" пропадает

ну так покажите, что там у вас.

особенно, если в дополнение использовать, например, blackbone.js

библиотеки-библиотеки-библиотеки не используйте их и проблем не будет

Вопрос: как можно это показать на диаграммах (например, UML)

точно также.

[lenok_sm]

Спасибо за отклик.
Ну, взять тот же пример от azproduction (http://habrahabr.ru/blogs/javascript/123635/):

var Module1 = {
   "init": function ($) {
      $.on('event', function (e) { // $ - не jQuery, это экземпляр sandbox
         console.log(e.data);
      });
   }
};
    
var Module2 = {
   "someAction": function ($) { // $ - не jQuery
      $.trigger('event', 'data');  
   }
};

Каким образом я могу показать это на UML? Попробую предположить использование диаграммы компонентов, но ведь js-модули бывают совсем не большие и скорее подходят на замену классам, чем компонентам.

[vflash]

lenok_sm, подход azproduction к модулям излишне усложнен.
если вам нужен какой-то функционал из другого файла просто подключайте его раньше вашего кода.

"класс" - это шаблон обьекта [+ конструктор]
модуль - это набор функционала.

[monolithed]

js-модули бывают совсем не большие и скорее подходят на замену классам

что такое модули, классы? - это объекты, т.е. сущности которые инкапсулируют некие данные (члены класса).

//инкапсуляция на основе замыкания
(function() {
	//объект/класс/конструктор Class
	var Class = function(id) {
		this.id = id;
	};

	//члены класса
	Class.prototype = {
		//свойство класса
		property : true,
		//метод калсса
		method : function() {
			return this.id;
		}
	};
	//экземпляр класса
	var foo = new Class(10);
	// метод экземпляра класса
	foo.method();
}());

PS: UML и JS слишком уж утопично, как мне кажется только время впустую потратите. т.к. псевдокод будет неполным, а генерация кода практически бесперспективна..

подход azproduction к модулям излишне усложнен.

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