1й пост я писал сильно под пивом. Рад что вообще хоть как-то попал в тему ))). Влюбом случае сейчас 5утра, спать неохото, а вот пофилосовствовать я люблю )) Тем более в 5 утра говорить больше нескем )))))
я немного напишу про свою архитектуру. Что-то из этого тебе должно пригодиться, постораюсь делать пометки на полезности.
Для проекта, использую JavaScriptMVC так как по сути он добавляет к jquery организацию кода и расширяет базовый функционал jquery.
Я использую 4х слойный клиент и это выглядит так.
Первый слой template. по сути шаблон для шаблонизатора. Шаблонизатор ejs, стандартный из поставки javascriptMVC. Во первых html не болтается в коде что упрощает понимание, во вторых за отдельный шаблон меня любят дизайнеры )). А ещё интерфейс можно набросать на этапе прототипирования приложения, ещё до того как всё это попадёт к js кодеру. Что сильно облегчает кодеру жизнь.
второй слой controller - здесь описана вся логика интерфейса. Обработка событий jquery. все возможный drag and drop и тд.
Из вкусняшек контролёра JavascriptMVC, обработка событий примерно таким макаром.
".knopka click":function(){
//полезный код который сработает при щелчке по элементу c классом knopka
}
и никаких click() и bind() мне не надо. Фреймворк сам использует их вместо меня.
Кстатии контролёр этого фреймворка очень сильно похож на jqueryUI только без его недостатков. + очень удобная система классов. К примеру у меня все плагины основанные на контролёрах, наследуют базовый функционал и стандартные обработчики событий от одного родительского класса.
// создаём контролёр горизонт на базе WidgetAdmin который мы создали заранее, и прописали там общие для всех контролёров методы, и обработчики событий.
WidgetAdmin.extend("horizont",{
// опции
options: {
greetings: "Hello"
},
// конструктор
init:function(el){
el.append("привет");
},
// обработчик
"button.knopka click":function(){
}
},
{
//всё что обьявлено здесь попадёт в прототип обьекта. Тоесть будет общим для всех экземпляров этого контролёра
);
// создаём контроллёр как любой виджет.
$("#test").horizont({
greetings:"astala vista"
});
Что может быть тебе полезно ? Интерфейс ты бы мог отлаживать без участия сервера, даже на локальном компьютере. Для взаимодействия с логикой приложения ты вызываешь методы из бизнес слоя. Методы бизнес слоя во время тестирования достаточно обьявить, а реализацией их заняться уже после того как закончишь с интерфейсом.
Дальше весело Ниже в MVC могла бы быть толстая модель, но мне не совсем это подходит, возможно не подойдёт и тебе.
бизнес слой. в моём случае логика приложения не то же самое что логика интерфейса, и что немаловажно может инициализироваться различными элементами интерфейса. К примеру алгоритм позиционирования виджетов на экране, может использоваться как при перемещение виджетов так и при их создании методом перетаскивания из тулбара. Так как перемещение виджетов и перетаскивание иконок два разных контролёра, то естественно всю общую логику позиционирования и перестановки/добавления я вынес в бизнес слой, а получившийся компонент назвал Arranger.
Что может быть полезно тебе. Бизнес слой ты можешь отлаживать при помощи тестов, незаморачиваясь на баги со стороны интерфейса. Так как роль контролёра сводится к инициализации бизнес процессов с определёнными параметрами, то тебе нечего не стоит написать тест который точно так же будет инициализировать эти процессы с параметрами, необходимыми тебе для тестирования.
Модель Здесь находятся данные, и основные методы работы с ними. В моём случае это оправдано желанием инкапсулировать данные общие для нескольких бизнес процессов в одном месте. В частности позиционирование виджетов, корзина, и система сохранения требует определять местоположение виджетов и оперировать ими на уровне контейнеров с учётом их вложенности. Поэтому я реализовал модель, абстракцию над DOM позволяющую работать на уровне контейнеров, роль хранилища данных при этом играет dom дерево браузера.
Особой выгоды в реализации моделей из фреймворка я пока неувидел, хватает и обычных обьектов играющих роль модели, но повторю это только мне и только пока.
в чём кайф для тебя. Обмен данных с сервером обычно производится на уровне модели. Но так как у тебя нет постоянного доступа к серверу, ты можешь имитировать взаимодействие с сервером на уровне модели. Так как бизнес процессы не имеют понятия о том как работает сервер, а общаться c сервером просят модель, то и подмену данных с сервера в модели на имитацию они не заметят. То есть ты сможешь выполнить отладку даже на локальном ПК, неприбегая к установке скрипта на сервер. Установка на сервер потребует только модификации модели, весь остальной код затронут небудет.
Теперь об общей композиции.
обычно хватает и трёх слоёв MVC, так как на клиентах обычно нет сложной бизнес логики.
-View в твоём случае это шаблон.
-контролёр - это логика пользовательского интерфейса плюс немного несложной логики приложения которую нет необходимости отлаживать и писать к ней тесты.
-Модель -данные, методы работы с данными(типо поиска и тд), взаимодействие с сервером и/или имитация взаимодействия.
> Если нужны тесты логики приложения, придётся создавать отдельный бизнес слой. тоесть вытащить всю бизнес логику из контролёра оставив ему только взаимодействие с пользователем.
> можно разместить конечно логику приложения и в модели, вместе с взаимодействием с сервером. Но если ты будешь, имитировать взаимодействие с сервером в перемешку с логикой приложения, это будет выглядить очень некрасиво, да и неудобно. Всё равно придётся выносить имитацию в отдельный слой на клиенте, или на какую то балванку серверной части предназначенную только для отладки клиента.
Что касается JavaScriptMVC. Вообще это самый логичный выбор фреймворка для любителей jquery, нравится мне в нём почти всё. И система классов, и события в контролёре, и шаблонизация строкой $(".iTarget").html("путь к шаблону",{данные для шаблона}). Однако управление модулями при помощи steal меня бесит, за месяц работы с этой штукой я так и несумел дать ей ума. Она или неподгружает скрипты или не передаёт команду на инициализацию или ещё что. Быть может я что-то нетак делаю, в конце концов меня это достало и я сделал свою реализацию, абстракцию над getScript из jquery которая проверяет был ли загружен уже данный скрипт а если нет то грузит. И наступило счастье.
уф, выдал
================================================== ============================================
2 часть ЭПОСА )).
Примечание 1.
Вообще не понятно что за сложности с установкой скриптов на сервер.
Я бы организовал работу таким образом чтобы каждый программист имел свою сборку, сборка js программистов, сборки php программистов и общая мастер сборка в которые входят последние стабильные js и php сборки. Если мастер сборка багов не выявила, то и js и php разработчики обьединяют свою локальную сборку с мастер сборкой, или берут за основу мастер сборку и работают дальше с ней как с локальной.
к недостаткам модели можно отнести просмотренные баги в мастер сборках, которые могут объявить в неподходящий момент и парализовать работу js или php кодеров по чужой вине. Впрочем чтобы php кодер не простаивал из за косяка js разработчика, он просто может поставить себе предыдущий стабильный релиз скрипта от js кодера, и продолжать разработку не дожидаясь пока js разработчик исправит баги. Для реализации этого даже репозитория некакого не надо, достаточно функции копирования в тотал командер и общедоступного ftp))))
Примечание 2.
Я тут подумал, что быть может нет вовсе необходимости постоянно ставить клиентский скрипт на сервер, возможно тебе достаточно повесить скрипт на обычную html'ку а с сервером общаться посредством кросс доменных запросов. Если конечно сервер доступен и хоть как-то работает, и туда выкладывают стабильные релизы от php кодеров, то такой чудиковатый подход мог бы проконать. Опять же так как всё общение с сервером проходит через модели, то как ты будешь делать запросы ты решаешь в модели. Следовательно остальной код твоей хитростью не задет. Ибо остальным слоям решительно пофиг откуда модели берут данные.
Но вот как то -так. Вообще очень мало инфы по архитектуре, подходам к разработки и так далее. Мне кажется было бы всем хорошо, если бы программисты делились подобным опытом. Программирование и написание программы, как ни странно разные вещи. И учиться этому приходится увы отдельно.
Однако утро, уже рассвело, пора спать ))))
зы.
|
Цитата:
|
утечка 
|
Это была не утечка, а реклама ))), Проект openSource, всё равно его скоро выкладывать в общий доступ.