Как я могу записать допускающий повторное использование JavaScript?

Базовый шаблон

Что касается вашего базового шаблона, могу ли я предложить изменить вашу структуру, чтобы использовать шаблон модуля и именованные функции:

var Search = (function(){
    var pubs = {};

    pubs.carSearch = carSearch;
    function carSearch(color) {
    }

    pubs.peopleSearch = peopleSearch;
    function peopleSearch(name) {
    }

    return pubs;
})();

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

Получение параметров

Одна из функций, которые мне очень нравятся из Prototype , - это функция Form # serialize , которая просматривает элементы формы и создает простой объект с свойство для каждого поля на основе имени поля. (Текущая реализация прототипа - 1.6.1 - имеет проблему, когда она не сохраняет порядок полей, но удивительно, насколько редко это проблема.) Похоже, что такие вещи вам пригодятся, и их несложно построить; тогда ваша бизнес-логика имеет дело с объектами со свойствами, названными в соответствии с тем, с чем они связаны, и не знает фактической формы.

Возвращаемые значения / Смешивание пользовательского интерфейса и логики

Я склонен думать о приложениях как об объектах, а также о связях и взаимодействиях между ними. Поэтому я стараюсь создавать:

• Объекты, представляющие бизнес-модель и тому подобное, независимо от интерфейса (хотя, конечно, бизнес-модель почти наверняка частично управляется интерфейсом). Эти объекты определены в одном месте, но используются как на стороне клиента, так и на стороне сервера (да, я использую серверную часть JavaScript) и разработаны с учетом сериализации (через JSON, в моем случае), поэтому я могу отправлять их туда и обратно. с легкостью.
• Объекты на стороне сервера, которые знают, как их использовать для обновления базового хранилища (поскольку я обычно работаю над проектами с базовым хранилищем), и
• Объекты на стороне клиента, которые знают, как использовать эту информацию для рендеринга в пользовательский интерфейс.

(Я знаю, вряд ли оригинально!) Я стараюсь сохранить общие для хранилища и рендеринга объекты, чтобы они в основном работали, глядя на общедоступные свойства бизнес-объектов (а это почти все свойства; я не использую паттерны, подобные паттернам Крокфорда, которые позволяют действительно скрывать данные, я считаю их слишком дорогими). Прагматизм означает, что иногда хранилище или объекты рендеринга просто должны знать, с чем они имеют дело, в частности, но я действительно стараюсь, чтобы вещи были общими, где я могу.