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

Что лучше выбрать 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

azesmcar, 

Сори, не заметил, что Вы отредактировали пост....  Мой пост потерял актуальность...

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

Я вроде добавлял только, не удалял ничего.

Просто, прочитав первый вариант Вашего сообщения,  я не совсем Вас понял и попросил уточнить. Но Вы уточнили раньше, чем я опубликовал свой пост  и как следствие - мой пост стал не актуален. 

Сейчас я понял Вашу мысль. 

Хотя говоря 


Я имел ввиду немного другое - что мы не сможем (как мне кажется) оставить на CGI/PHP/Perl/Python/Tcl только представление.  Придется писать какую-то часть логики, что приведет к усложнению отладки.



Я имел ввиду http://ru.wikipedia.org/wiki/Model-View-Controller 



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

эммм, да. тут вы правы, полностью разделить бизнес логику и гуи к сожалению не получается. Тут отладка немного усложнится, но не так чтобы боятся этого.. в конце концов DLL не только в этом случае пишут. Отлаживают же.


теперь понял.

Частично бизнес-логика выноситься на скл сервер в виде хранимых процедур и триггеров.

В принципе эту дискуссию можно прекратить, так как я уже определился с языком. И соответственно прекратил развивать одно из направлений   

Это сообщение отредактировал(а) aliks - 10.6.2009, 10:24

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

поделитесь..

Это не хитрость, а просто дипломатия   

Выбор все таки пал на Java. Аргументы:

1. Одним из главных аргументов в данной ситуации, а я думаю, что такая ситуация встречается практически у каждого это скорость разработки проекта.
1.1 Наличие удобной среды разработки
1.2 Наличие большого количества сторонних компонентов (классов), из которых можно выбирать по мере необходимости

Для данной работы все таки по моему мнению, лучше подходит Java. К такому выводу я пришел после 6 месячного изучения/работы с этими языками. До этого я 8 лет работал исключительно с Delphi, поэтому мне было важно и самому попробовать и услышать чужое мнение.