Разрабатывается кростплатформенное приложение клиент-сервер

Что лучше выбрать Java или Qt

Пожалуйста приведите аргументы

Возможно вы мне не поверите, но информации явно недостаточно. К тому же эта тема для религиозных войн. 
приложение написанное с использованием QT не кроссплатформенно, код кросплатформенный. Т.е. у вас будут разные версии для каждой ОС. Но это будет 100% машинный код. 

Это сообщение отредактировал(а) azesmcar - 4.6.2009, 11:13

Я понимаю что именно код кросс-платформенный

aliks

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

Добавлено через 47 секунд
А тему то уже перенесли  

Личных предпочтений нет, так как и с Java и с Qt работаю относительно недавно. Делается проект по технологии клент сервер, в качестве сервера используется MySQL. Программа будет нечто похоже на бухгалтерию, отслеживание движения товара. Предпологается запускать программу как под виндой так и под линуксом. Честно говоря, у меня есть уже наработки по этому проекту в обоих вариантах. Есть и там и здесь плюсы и минусы. Сам склоняюсь к одному из вариантов, которых пока не хочу озвучивать. Хотелось услышать постороннее мнение

aliks, 



Вы таким образом хотели сказать, что у Вас двкхзвенная архитектура (БД - клиент)? 

приложение клиент-сервер обычно подразумевает трехзвенную архитектуру  (БД - сервер - клиент), что дает большую гибкость, масштабируемость и безопасность. 

Я бы выбрал ни то, ни другое.
WEB  
а на эту тему религиозная война у нас уже была   

azesmcar, 



А чем для WEB плоха Java?  
К тому же можно сразу сделать и Web и десктоп с минимумом лишнего кода.

Java для веб - имеется ввиду JSP? Тогда не получится тот же код и для десктопа и для веб. А если писать аплет - тогда какая разница веб или десктоп. Это практически одно и тоже, просто открывается не в отдельном окне а в браузере. Хотя не исключено что я просто чего-то не знаю, я все таки не очень близко знаком с Java. А  так вообще - ничем неплох  просто если писать Web - тут выбора больше. Можно еще подумать и почитать.  может есть личные предпочтения 

Это сообщение отредактировал(а) azesmcar - 5.6.2009, 19:09

azesmcar, 


JSP - это только один из вариантов реализации view. Для десктоп приложения придется писать свое view, используя, например, swing.
Однако реализация бизнес-логики может быть одинаковой для web  и  десктоп приложения (а это, впринципе, основная часть кода) - тут, конечно, есть варианты реализации, конечный выбор которых зависит от условий задачи. 



Это сообщение отредактировал(а) Vasay - 5.6.2009, 19:37

Ну если отделить только бизнес логику - то да.  Но в таком случае можно использовать любой ЯП. Java преимуществ не дает. Написать к примеру бизнес логику на QT в виде DLL (so) и загружать эту DLL в CGI/PHP/Perl/Python/Tcl так можно продолжать бесконечно 

хотя не надо слишком прислушиватся к этому..мое мнение предвзято..
но мы же в религиозных войнах   

Это сообщение отредактировал(а) azesmcar - 5.6.2009, 20:12

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

Кроме того, используя такие фрэймворки как spring писать иначе, просто не получится 



А как все это отлаживать? ИМХО - это уже камасутра. 



Попробуйте Spring и поймете, какие преимущества дает. 

Нет, я сказал не отделить бизнес логику, а отделить только бизнес логику. Имелось ввиду интерфейс писать для каждого свой.


Ну присойденять надо в уже отлаженном состоянии. Прежде чем присупить к рисованию - бизнес логике должна стабильно работать, ну более менее 



А мне оно надо  когда мне начнут за это платить тогда и попробую..а пока - верю на слово 

Гм... могу быть конечно не прав, но Controller нам придется писать на CGI/PHP/Perl/Python/Tcl , так как ек вижу не извращенного способа вынести его в модуль на so/dll

Это сообщение отредактировал(а) Vasay - 5.6.2009, 21:04

Ну, насчет CGI - если это C++ все просто. A вот для остальных есть SWIG. Писать ничего не надо, он сгенерирует враперы. Я сам использовал только для Tcl, но он генерирует и для

Далее после компиляции специальной библиотеки идет обыкновенный вызов функции DLL, также как родных функций самого скрипта/языка.
Для примера в Tcl будет так


Тут есть один минус - мы теряем возможность иметь обьектно-озабоченный интерфейс - но я предпочитаю реализовывать бизнес логику в виде API функций.
И у этого подхода даже есть множество плюсов. Кроме интерфейса мы можем дать клиенту DLL. Записать на диск чуть модернизированный интерпретатор какого нибудь скриптового языка (пусть это будет Perl) , чтобы он автоматически подгружал нужную библитеку и сказать что наша программа поддерживает script programming. Вся логика то в DLL реализована. 

Или я не так понял значение слова Контроллер?

Это сообщение отредактировал(а) azesmcar - 5.6.2009, 21:31