Управление проектом веб-приложения с несколькими режимами просмотра

Question

Какова общая практика при разработке веб-приложения, которое должно быть реализовано в нескольких режимах просмотра, то есть на рабочем столе и на мобильном телефоне / iPhone?

Лучше ли разрабатывать несколько приложений для каждого режима или пытаться сохранить весь код в одном приложении? Имеет ли значение, если все функциональные возможности страницы одинаковы (то есть иногда мобильные версии не могут «делать» то, что могут их веб-аналоги)? Каковы некоторые критерии, чтобы решить, следует ли разделить приложение на несколько проектов, ошибок и т. Д.? Существуют ли какие-либо конкретные архитектурные шаблоны, облегчающие работу?

Мне кажется, что если приложение не может быть просто представлено в разных видах, лучше создать отдельное приложение для каждого.

Предположим, что приложение похоже на Gmail или Facebook (более крупное приложение с множеством функций), а не на простой привет тип или статичный корпоративный веб-сайт.

В настоящее время я использую Grails для разработки, но, вероятно, это применимо к нескольким фреймворкам.

Answer 1

1) Центральная база данных для всего

2) Один, центральный уровень бизнес-логики. Это могут быть веб-службы, javabeans и т. Д. Может существовать бизнес-логика только для Интернета или только для мобильных устройств. Ничего, оставь все в одном месте.

3) Несколько уровней презентации. Уровень веб-презентации будет вызывать веб-службы и генерировать их для обычного браузера. Уровень представления мобильных данных будет вызывать те же функции, но представлять их оптимизированными для мобильного использования.

Если вы сделали несколько проектов, исправив одну ошибку или добавив одну функцию, это означало бы, что вам придется делать это на двух разных сайтах, тем самым удваивая время сборки и исправления ошибок.

В качестве альтернативы, вы можете оставить все «под прикрытием» одинаковым на уровне бизнес-логики и позволить людям видеть различные представления этой бизнес-логики как веб-сайт или мобильный сайт.

Надеюсь, это поможет.

Answer 2

Как уже упоминалось выше, разделение проблем важно.

После этого вопрос о том, создавать ли отдельные уровни представления / приложения, действительно является решением, которое должно приниматься на основе различных параметров (т. Е. Ресурса, времени, стоимости, масштабируемости и т. Д.).

Я предлагаю исследовать шаблоны проектирования MVC / MVP, отделить логику представления от бизнес-логики и рассмотреть вопрос о том, как ваше приложение будет представлено на каждой платформе и куда лучше всего инвестировать свое время и деньги.

Answer 3

Вы определенно не хотите два приложения. Попробуйте отделить бизнес-логику и логику контроллера от представления.

В зависимости от сложности приложения, разница может составлять всего лишь дополнительный файл css с медиа-типом «handheld» для отдельного внутреннего веб-сервиса (как указано выше). В середине, чтобы весь ваш серверный код следовал шаблону

1. Сбор требований
2. Запуск бизнес-логики, сохранение значения для просмотра где-либо
3. Выясните, какой вид использовать
4. Создать представление

Это особенно хорошо работает для систем, которые используют шаблонное представление (JSP, Rails и т. Д.), Но может быть сделано и для PHP.

Внутренний веб-сервис - это хорошая идея, если у вас, вероятно, будет еще больше дисплеев для веб-сайта, если интерфейс хорошо работает с веб-сервисами или если интерфейсы разрабатываются отдельными сторонами.

Answer 4

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

Для платформ Microsoft хорошими вариантами здесь являются службы данных ASP.NET MVC или ADO.NET. Уровень представления должен быть полностью разделен на другой проект, чтобы обеспечить его независимость от бизнес-логики.

Но на других платформах должно быть так же легко сделать это, используя подход RESTful.