AJAX
Я думаю, что ваш вопрос сводится к: «Должно ли мое веб-приложение генерировать HTML на стороне клиента или на стороне сервера?» Генерация на стороне клиента связывается с сервером с помощью AJAX, хотя X (XML) обычно заменяется на JSON, но большинство людей все еще называют его AJAX, потому что он звучит лучше. На стороне сервера сервер просто создает HTML на сервере.
У меня большой опыт работы с XML и почти нет опыта работы с JSON. Все, что я знаю о XML, заставляет меня предложить вам использовать JSON, если это вообще возможно.
AJAX Pros:
- Отправляйте меньше данных по HTTP (S), чтобы они могли работать быстрее.
- Сервер по сути является веб-службой, так что другие люди (или вы) могут писать свои собственные клиенты. Это может помочь при создании мобильной версии вашего сайта. Кроме того, многие изобретения становятся популярными по причинам, о которых их создатель никогда не задумывал. Сервисы удобнее для людей, которые находят новые варианты использования вашего кода.
- Выглядит как новое приложение
Минусы AJAX:
- Отладка JavaScript
- Сложность?
- То, что вы можете сделать с помощью JavaScript, часто совершенно невозможно для слепых или людей с ограниченными возможностями.
- Может потребоваться больше кода (больше общего хранилища на встроенном устройстве)
Клиент / сервер
Все веб-приложения используют архитектуру клиент-сервер. Протокол HTTP заставляет веб-приложения вести себя таким образом. AJAX использует обходной путь для этого ограничения дизайна, но базовой базовой моделью HTTP по-прежнему остается клиент-сервер. Я бы не стал зацикливаться на том, как лучше всего применять MVC для веб-приложений. Если вам нужно сделать MVC по политическим причинам, посмотрите, как это делает Ruby / Rails. На самом деле Rails - отличная архитектура для копирования (или использования).
Сервис против приложения.
Хороший сервис почти всегда лучше, чем приложение. Но сделать хороший сервис сложно! Возможно, вам придется подать заявку, прежде чем вы сможете написать достаточно хорошо спроектированную спецификацию для сервиса. Не делайте свою работу более сложной, чем она должна быть. Для версии 1 сфокусируйтесь на создании отличного приложения. Пока ваше приложение не будет относительно стабильным и вы уверены, что оно соответствует требованиям вашего пользователя, вероятно, наличие службы в любом случае не принесет вам пользы. Слишком раннее проектирование неправильной службы - это пустая трата времени, которое тратится впустую, когда вы пытаетесь исправить интерфейс службы и иметь дело с массовым рефакторингом кода сервера и клиента, который последует.
C / Web
Вау. Я работал в C и Assembly в течение 3 лет, прежде чем я переключился на веб-разработку. Я не могу придумать худший язык для написания веб-приложений - особенно с точки зрения безопасности. Проверка входных данных и выходной выход настолько важны ... SANS публикует список самых распространенных ошибок каждый год. Переполнения буфера, инъекции, проблемы между сайтами (неправильная кодировка вывода) ... Все эти ошибки действительно легко сделать в C или сборке. По крайней мере, в языке, подобном Java, есть строка, защищенная от переполнений, и механизм обработки исключений, который, как правило, предотвращает случайные ошибки, позволяющие вредоносному коду получать доступ к системной памяти. Не говоря уже об обработке международных наборов символов (используйте UTF-8, когда это возможно).
Если вам нужно использовать C по причинам памяти или прошивки, то это то, что вам нужно сделать. Просто будь осторожен!
Поддержка браузера
Первый шаг к созданию веб-приложения - определить, какие браузеры будут использоваться вашими клиентами? W3Schools и Wikipedia являются хорошими источниками общей статистики, но YMMV.
Там, где я сейчас работаю, мы проверяем, что наше приложение создает только действительный переходный HTML XHTML 1.0. Мы также используем определенный тип документа и форматирование, необходимые для того, чтобы избежать в Quirks Mode в IE, что облегчает написание кросс-браузерного HTML (см. Советы в моем блоге ). Мы тестируем последние 3 версии IE, а также Firefox и Chrome для Windows и Linux (Safari использует тот же механизм рендеринга, что и Chrome). После этой проверки и тестирования наше приложение работает практически везде (Windows, Mac, Linux, iPhone, Android и т. Д.), За исключением BlackBerry.
У BlackBerry никогда не было настоящего браузера с JavaScript, поэтому мы его не поддерживаем. Пользователи BlackBerry привыкли не иметь настоящий веб-браузер, поэтому они не жалуются. Может быть, это меняется? Я хотел бы спросить нескольких клиентов, какие браузеры они используют, и обязательно протестировать их.
Резюме
Все веб-сайты построены на HTML и HTTP. Имейте хорошую справочную информацию об этих технологиях под рукой, пока вы делаете свое заявление. В процессе создания приложения, даже с инструментарием, вы столкнетесь с проблемами, которые требуют базового понимания этих технологий для их решения.
Вам, вероятно, также нужно быть уверенным в CSS и сжатии изображений, чтобы сделать что-то, что выглядит прилично и быстро реагирует. JavaScript, веб-серверы и браузеры - это дополнительные области знаний, которые вам в конечном итоге понадобятся.
Если вы строите свой HTML на стороне сервера, ваша кодовая база, вероятно, будет меньше, и вам, возможно, не потребуется изучать JavaScript. Модель на стороне сервера означает, что ваши программисты будут писать (C?) Код, который генерирует HTML, который они могут просматривать непосредственно перед его отправкой клиенту. Модель AJAX означает, что ваши программисты будут писать JavaScript, который генерирует HTML. Я не знаю много инструментов для проверки или даже просмотра HTML-кода, сгенерированного JavaScript в браузере, что затрудняет правильное программирование.
Там, где я сейчас работаю, мы используем гибридный подход, который иногда включает в себя код Java, который генерирует JavaScript, который генерирует HTML. Если вы, ребята, новички в веб-разработке, начинать не с этого. Думаю, я должен был бы сказать, что если у вас нет веских причин для использования модели AJAX, я бы начал с более старой модели генерации HTML на стороне сервера и посмотрел, как далеко она вас зашла.