Страницы

Поиск по вопросам

четверг, 13 февраля 2020 г.

Выбор платформы PHP или Java?

#php #java #веб_программирование


Выбираем, пробуем разные платформы для разработки web-приложения (тонкий клиент,
важно для платформ iOS), у которого должна быть кросс платформенная оффлайн версия.
Запутался уже совсем, думал на Java писать, похоже, для нашего несложного приложения
вполне подходит PHP (его и изучать проще), на PHP реализовано немало проектов и такие
высоконагружные как ВКонтакте.
Главная сложность нашего проекта состоит в том, что онлайн и оффлайн версии должны
иметь один код и один интерфейс (чтобы не пришлось их отдельно писать).  

Решение видим следующие:  


Писать десктопное Java приложение и развертывать его на сервере.
Для запуска настольной версии на Windows, Linux, (Mac OS?) нужно только JVM установить.
На сервере можно как апплет или JWS оформить (вопрос относительно тонкого клиента
придется решать?).
Писать web-приложение на JavaEE, работающее на GlassFish например.
Настольную версию предлагается делать следующим образом: запускать локальный сервер
GlassFish, на котором выполняется наше приложение. Похож на какой-то кустарный метод?
Вопрос удобства для пользователя - установка и настройка сервера, возможные подводные
камни?  
Писать на PHP.
Схож с пунктом 2, с серверами только вроде попроще?  


Вопрос бредовый, тем не менее хотелось бы узнать ваши комментарии, какие еще есть
варианты?
Предыдущие темы:
Язык программирования для Web-приложений
Развертывание приложений Java на сервере
Оффлайн запуск web-приложений   
    


Ответы

Ответ 1



Посмотрите на Adobe Air, он позволит написать кросплатформенное приложение не только на все десктоп платформы, но и на iOS, и веб часть на флеше.

Ответ 2



Дополню ответ @ArtFeel. Adobe Flex + AIR в вашем случае, возможно, единственное разумное и доступное решение. Ниже делюсь личным опытом разработки решения с аналогичными требованиями. Вы получите из одного и того же кода практически: Десктопный клиент (AIR). Клиент для браузера (Flash). Клиент для коммуникаторов (Flash). Но будут определенные ограничения архитектурного плана. Web-сервис в данном случае можно будет писать на чем угодно - его задачей будет только прием и возврат данных, вполне сойдет и PHP, если есть ограничения по времени на освоение технологий. Лично я бы выбирал между REST-службой на Java (Jersey) и REST-службой на Ruby (Ruby On Rails), оба варианта позволят быстро и просто сделать сервис для выполнения CRUD операций, HTTPS на Java поднимается за 5 минут. В качестве транспорта данных - просто XML или JSON (я бы выбрал второй). Клиент будет "толстым" - вся логика приложения должна быть сосредоточена в нем. Кроме того, в клиенте организуете абстрактный слой доступа к данным, через который приложение будет читать-писать. Для конкретных источников данных пишите соответствующие реализации: для связи с web-сервисом, для локального desktop-хранилища, для локального хранилища на мобильных платформах. В зависимости от внешних условий (с какой платформы запущено и есть ли связь с сервером) приложение включает конкретную реализацию слоя доступа к данным.

Комментариев нет:

Отправить комментарий