Базовая модель
С точки зрения вашего базового шаблона, могу ли я предложить изменить вашу структуру для использования шаблона модуля и именованных функций:
var Search = (function(){
var pubs = {};
pubs.carSearch = carSearch;
function carSearch(color) {
}
pubs.peopleSearch = peopleSearch;
function peopleSearch(name) {
}
return pubs;
})();
Да, это выглядит сложнее, но это отчасти потому, что не задействована вспомогательная функция. Обратите внимание, что теперь у каждой функции есть имя (ваши предыдущие функции были анонимными; у свойств, с которыми они были связаны, были имена, а у функций - нет, что имеет значение с точки зрения отображения стека вызовов в отладчиках и тому подобном). Использование шаблона модуля также дает вам возможность иметь полностью закрытые функции, к которым могут обращаться только функции в вашем Search объекте. (Просто объявите функции в большой анонимной функции и не добавляйте их в pubs.) Подробнее об этом я расскажу (с преимуществами и недостатками, а также с тем, почему вы не можете объединить объявление функции и назначение свойства) здесь .
Получение параметров
Одна из функций, которые мне действительно очень нравятся из Прототип - это функция Form#serialize, которая проходит по элементам формы и создает простой объект со свойством для каждого поля. на основе названия поля. (Текущая реализация прототипа - 1.6.1 - имеет проблему, когда она не сохраняет порядок полей, но удивительно, как редко это является проблемой.) Звучит так, как будто вы хорошо обслуживается такими вещами, и их не сложно построить; тогда ваша бизнес-логика имеет дело с объектами со свойствами, названными в соответствии с тем, с чем они связаны, и не знает самой действительной формы.
Возвращение значений / Смешивание пользовательского интерфейса и логики
Я склонен думать о приложениях как об объектах, а также о связях и взаимодействиях между ними. Поэтому я склонен создавать:
- Объекты, представляющие бизнес-модель и тому подобное, независимо от интерфейса (хотя, конечно, бизнес-модель почти наверняка частично управляется интерфейсом). Эти объекты определены в одном месте, но используются как на стороне клиента, так и на стороне сервера (да, я использую серверную часть JavaScript) и разработаны с учетом сериализации (в моем случае, через JSON), чтобы я мог отправлять их туда и обратно легко.
- Отказывается от серверной стороны, которая знает, как использовать их для обновления основного хранилища (поскольку я, как правило, работаю над проектами с базовым хранилищем), и
- Объекты на стороне клиента, которые знают, как использовать эту информацию для визуализации в пользовательском интерфейсе.
(Я знаю, вряд ли оригинально!) Я пытаюсь сохранить хранилище и рендеринг объектов, чтобы они в основном работали, просматривая общедоступные свойства бизнес-объектов (а это почти все свойства; я не использую шаблоны, подобные Крокфорду, которые позволяют вам действительно скрывать данные, я считаю их слишком дорогими). Прагматизм означает, что иногда хранилищу или объектам рендеринга просто необходимо знать, с чем они имеют дело, в частности, но я стараюсь держать вещи в общих чертах там, где могу.