| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Религиозные войны > Java vs Qt |
| Автор: aliks 4.6.2009, 11:00 |
| Разрабатывается кростплатформенное приложение клиент-сервер Что лучше выбрать Java или Qt Пожалуйста приведите аргументы |
| Автор: azesmcar 4.6.2009, 11:08 | ||
Возможно вы мне не поверите, но информации явно недостаточно. К тому же эта тема для религиозных войн. приложение написанное с использованием QT не кроссплатформенно, код кросплатформенный. Т.е. у вас будут разные версии для каждой ОС. Но это будет 100% машинный код. |
| Автор: aliks 4.6.2009, 11:38 |
| Я понимаю что именно код кросс-платформенный |
| Автор: azesmcar 4.6.2009, 12:27 |
| aliks Если вы не хотите превратить тему в бессмысленную войну, сообщите побольше о задаче. Я же сказал, информации недостаточно. Язык программирования выбирают исходя из задачи. А из задачи известно только что нужна кроссплатформенность. Плюс здесь может сыграть роль личные предпочтения если для задачи подходят оба. Добавлено через 47 секунд А тему то уже перенесли  |
| Автор: aliks 5.6.2009, 16:29 |
| Личных предпочтений нет, так как и с Java и с Qt работаю относительно недавно. Делается проект по технологии клент сервер, в качестве сервера используется MySQL. Программа будет нечто похоже на бухгалтерию, отслеживание движения товара. Предпологается запускать программу как под виндой так и под линуксом. Честно говоря, у меня есть уже наработки по этому проекту в обоих вариантах. Есть и там и здесь плюсы и минусы. Сам склоняюсь к одному из вариантов, которых пока не хочу озвучивать. Хотелось услышать постороннее мнение |
| Автор: Vasay 5.6.2009, 17:19 | ||
aliks,
Вы таким образом хотели сказать, что у Вас двкхзвенная архитектура (БД - клиент)? приложение клиент-сервер обычно подразумевает трехзвенную архитектуру (БД - сервер - клиент), что дает большую гибкость, масштабируемость и безопасность. |
| Автор: azesmcar 5.6.2009, 17:30 | ||
Я бы выбрал ни то, ни другое. WEB  а на эту тему религиозная война у нас уже была |
| Автор: Vasay 5.6.2009, 17:58 | ||
azesmcar,
А чем для WEB плоха Java? К тому же можно сразу сделать и Web и десктоп с минимумом лишнего кода. |
| Автор: azesmcar 5.6.2009, 19:05 | ||
Java для веб - имеется ввиду JSP? Тогда не получится тот же код и для десктопа и для веб. А если писать аплет - тогда какая разница веб или десктоп. Это практически одно и тоже, просто открывается не в отдельном окне а в браузере. Хотя не исключено что я просто чего-то не знаю, я все таки не очень близко знаком с Java. А так вообще - ничем неплох  просто если писать Web - тут выбора больше. Можно еще подумать и почитать. может есть личные предпочтения |
| Автор: Vasay 5.6.2009, 19:33 | ||
azesmcar,
JSP - это только один из вариантов реализации view. Для десктоп приложения придется писать свое view, используя, например, swing. Однако реализация бизнес-логики может быть одинаковой для web и десктоп приложения (а это, впринципе, основная часть кода) - тут, конечно, есть варианты реализации, конечный выбор которых зависит от условий задачи. |
| Автор: azesmcar 5.6.2009, 20:01 | ||
Ну если отделить только бизнес логику - то да. Но в таком случае можно использовать любой ЯП. Java преимуществ не дает. Написать к примеру бизнес логику на QT в виде DLL (so) и загружать эту DLL в CGI/PHP/Perl/Python/Tcl так можно продолжать бесконечно хотя не надо слишком прислушиватся к этому..мое мнение предвзято.. но мы же в религиозных войнах  |
| Автор: Vasay 5.6.2009, 20:20 | ||||||
Отделять бизнес-логику - это хороший тон, на чем бы вы не писали. Кроме того, используя такие фрэймворки как spring писать иначе, просто не получится
А как все это отлаживать? ИМХО - это уже камасутра.
Попробуйте Spring и поймете, какие преимущества дает. |
| Автор: azesmcar 5.6.2009, 20:26 | ||||||
Нет, я сказал не отделить бизнес логику, а отделить только бизнес логику. Имелось ввиду интерфейс писать для каждого свой.
Ну присойденять надо в уже отлаженном состоянии. Прежде чем присупить к рисованию - бизнес логике должна стабильно работать, ну более менее
А мне оно надо когда мне начнут за это платить тогда и попробую..а пока - верю на слово |
| Автор: Vasay 5.6.2009, 21:03 | ||
Гм... могу быть конечно не прав, но Controller нам придется писать на CGI/PHP/Perl/Python/Tcl , так как ек вижу не извращенного способа вынести его в модуль на so/dll |
| Автор: azesmcar 5.6.2009, 21:11 | ||||||
Ну, насчет CGI - если это C++ все просто. A вот для остальных есть http://www.swig.org/. Писать ничего не надо, он сгенерирует враперы. Я сам использовал только для Tcl, но он генерирует и для
Далее после компиляции специальной библиотеки идет обыкновенный вызов функции DLL, также как родных функций самого скрипта/языка. Для примера в Tcl будет так
Тут есть один минус - мы теряем возможность иметь обьектно-озабоченный интерфейс - но я предпочитаю реализовывать бизнес логику в виде API функций. И у этого подхода даже есть множество плюсов. Кроме интерфейса мы можем дать клиенту DLL. Записать на диск чуть модернизированный интерпретатор какого нибудь скриптового языка (пусть это будет Perl) , чтобы он автоматически подгружал нужную библитеку и сказать что наша программа поддерживает script programming. Вся логика то в DLL реализована. Или я не так понял значение слова Контроллер? |
| Автор: Vasay 5.6.2009, 21:32 |
| azesmcar, Сори, не заметил, что Вы отредактировали пост.... Мой пост потерял актуальность... |
| Автор: azesmcar 5.6.2009, 21:39 |
| Я вроде добавлял только, не удалял ничего. |
| Автор: Vasay 5.6.2009, 21:54 | ||||||
Просто, прочитав первый вариант Вашего сообщения, я не совсем Вас понял и попросил уточнить. Но Вы уточнили раньше, чем я опубликовал свой пост и как следствие - мой пост стал не актуален. Сейчас я понял Вашу мысль. Хотя говоря
Я имел ввиду немного другое - что мы не сможем (как мне кажется) оставить на CGI/PHP/Perl/Python/Tcl только представление. Придется писать какую-то часть логики, что приведет к усложнению отладки.
Я имел ввиду http://ru.wikipedia.org/wiki/Model-View-Controller |
| Автор: azesmcar 5.6.2009, 22:01 | ||||
эммм, да. тут вы правы, полностью разделить бизнес логику и гуи к сожалению не получается. Тут отладка немного усложнится, но не так чтобы боятся этого.. в конце концов DLL не только в этом случае пишут. Отлаживают же.
теперь понял. |
| Автор: aliks 10.6.2009, 10:20 |
| Частично бизнес-логика выноситься на скл сервер в виде хранимых процедур и триггеров. В принципе эту дискуссию можно прекратить, так как я уже определился с языком. И соответственно прекратил развивать одно из направлений |
| Автор: zloyGamer 13.6.2009, 17:01 | ||||
aliks - такой хитрый тип..
так ничего и не сказал по поводу выбора.., какой язы и почему, за эти 6 дней весь мозг мне разрушил а я так и неузнаю к чему пришли...поделитесь.. |
| Автор: aliks 18.6.2009, 11:40 |
Это не хитрость, а просто дипломатия  Выбор все таки пал на Java. Аргументы: 1. Одним из главных аргументов в данной ситуации, а я думаю, что такая ситуация встречается практически у каждого это скорость разработки проекта. 1.1 Наличие удобной среды разработки 1.2 Наличие большого количества сторонних компонентов (классов), из которых можно выбирать по мере необходимости Для данной работы все таки по моему мнению, лучше подходит Java. К такому выводу я пришел после 6 месячного изучения/работы с этими языками. До этого я 8 лет работал исключительно с Delphi, поэтому мне было важно и самому попробовать и услышать чужое мнение. |
