Прощай боланд?! :)
Переходить на студию 2009 особого смысла не вижу - но может ошибаюсь?
Видимо имелось ввиду один язык программирования. Но в принципе студию считать венигретом тоже не совсем верно - есть системообразующее ядро (если говорить о дотнет) и языки которые реализуют некоторое множество из его функциональности - причем ни один в полной мере, за исключением ассемблера. А некоторая функциональность доступна только на нем. В принципе RAD2006-09 тоже пошла по такому же пути - но вот тут уже и получился венегрет. Потому что например не понятно в чем сакральный смысл включения делфи и билдера в одну RAD - ведь языки практически полностью решают одни и те же задачи? Несмотря на гордую приставку Ц плас плас, использовать ВСВ за пределами задач работы с БД особого смысла не имеет. Делфи в принципе тоже в основном заточен под тоже. И все это густо замешано на дотнет - но при этом практически отсутствует жесткий стандартный подход, как вижуале. Ну и к этому еще добавить что центр разработки дотнет пока еще расположен в Редмонте, а отнюдь не в Остине - и любая попытка писать среду разработки для дотнет за его пределами фактически превращает компанию в кузницу кадров для Microsoft. В общем такое себе противостояние Севера и Юга в современном исполнении. :)
В принципе, Кот осветил вопрос с одной стороны (языково-платформенной). Я с другой зайду - VS2008 из коробки предлагает минимум 3 ключевых подхода для построения десктопного приложения: ATL/MFC (я их особо не различаю, не пинайте), WinForms, WPF. RAD2009 сейчас пошел по этой же стезе: есть возможность использовать VCL (Delphi/C++), есть возможность использовать WinForms (Delphi/C#/VB.NET). Если товарищ lena_ki расскажет больше - буду рад. Я например не в курсе серверной стороны вопроса в RAD2009. Веб-сервисы насколько легко сделать, с БД насколько продвинуто можно общаться/ругаться. Просто времени изучать всякие DataSnap нету - у меня своих задач хватает. Ссылками-то кидаться любой может...
Ну вобщето - то что Лена почему то позиционирует как новейшую технологию в 2009 среде - в меру успешно работало начиная с 5 версии. Если по искать по теме с год или два назад было даже обсуждение где я описывал что даже на локальной машине для работы с БД желательно использовать связку компонент доступа к данным - DataSetProvaider - ClientDataSet. А данную методику я позаимствовал в свою очередь.
Как насчет официального сайта компании: http://www.codegear.com/shop/resellers
Впрочем,
Если быстрота и удобство разработки на последнем месте, то тогда, действительно стоит посмотреть в сторону других IDE, ведь RAD 2009 служит именно для быстрой и удобной разработки: Rapid Application Development
Что касается переноса старых проектов, то особых проблем у моих знакомых с этим не наблюдалось.
Что касается IntraWEB, то, наверное, лучше просто построить тестовое web ориентированное приложение с опорой на базы данных, развернуть его на сервере и проверить работу и свои трудозатраты на все это, думаю, так лучше будет сделать выводы…
Я скептически к этому отношусь. Поскольку некоторые поставщики инструментов и платформ, кажется (не буду тут называть имена), именно так и рассуждают - "Поскольку пользователь будет делать вывод на основании внешних фич, которые увидит и которыми восхитится, прежде всего надо предоставить такие фичи, чтобы пользовать мог делать простые и тривиальные вещи (а другие в демо мы и не сможем показать) буквально щелчком пальцев. А проблемы, возникающие при реализации сложных нетривиальных вещей - ну это потом, по мере появления, когда выйдем на большой рынок, когда привлечем инвесторов, и т.п."
В итоге, бывает что некоторый поставщик поставляет решение, в котором тривиальные задачи, вроде тех что вы описали (тестовое приложение, веб, связанное с БД, классический пример из чуть более чем всех статей по веб/enterprise программированию), действительно решаются мгновенно. Ну, разве что там кнопки нет - "Сделать все ОК!"
А вот когда доходит до того, чтобы написать с помощью такого решения что-то нетривиальное, то возникают проблемы, потому что интерфейсов расширения у такого решения часто нету. Что есть - работает, а уж чего нет - того нет, извините.
Потому, в нашей например компании (не пропагандирую, но просто пример), когда Technical Expertise Group рассматривает новый фреймворк для включения в стек технологий компании - в первую очередь мы смотрим не на то, есть ли у него поддержка из коробки от какой-то определенной IDE, есть ли там визарды которые умеют создавать забавные тестовые приложения за 5 кликов и прочее.
Тривиальные вещи вроде опять же, того приложения что вы описали, мы и сами отлично умеет делать ;)
А на что мы смотрим? Да наверное на тоже что и Кот, только добавлю еще:
Как он поддерживается, насколько стабилен вендор, в перспективе не вытесняют ли его с рынка. Насколько у него стабильная кодовая база, как работает его support community, какая политика включения новых фич, релизов. Насколько расширяема архитектура, чтобы писать свои плагины и реализации интерфейсов, потому что их все равно надо будет писать. Насколько он generic чтобы можно было эффективно строить различные бизнес-модели поверх него, меняя только файлы конфигурации. Как этот фреймворк сможет взаимодействовать с тем что уже у нас есть. И так далее.
К вопросу о времени -я лучше скажу так. Не важно, смогу ли я с сделать с помощью чего то тривиальную вещь за день или за 3 часа. Важно, смогу ли я сделать нормальным цивилизованным образом сложную нетривиальную вещь за разумное время (скажем, через строго документированный интерфейс плагинной шины, как в Eclipse RCP/OSGi), или же для этого придется делать форк фреймворка / копаться в недокументированных исходниках / декомпилировать / посреди работы бросать этот фреймворк и переходить на другой/ добавлять еще один сторонний фреймворк только для того, чтобы поддержать один специальный важный случай...
Я донес свою мысль? :)
Веб приложения для учета автомолилей, или чего там.
Скажите, как у вас реализованы страницы?
Когда в приложении скажем, 50 базовых моделей, и на них построено скажем, сотни кастомных моделй, и для всех нужны страницы search/detail vew / update / create /, очевидно что создание новой страницы (или аналогичного по гранулярности объекта) для каждой кастомной модели сдыхает. Требуется, чтобы можно было описать структуру всех меню и UI components в нескольких конф. файлых, XML. UI Meta Model concept. А сами страницы (серверные, JSP, для Java например), генерились динамически, потом компилировались, потом генерили разметку и отдавали на клиента. Насколько легко/трудно такое сделать?
Если про ВСВ6 говорить, то естествненно того что связано с НЕТ там нет(WinForms, WPF). А поддержка других популярных технологий присутствует, например ActiveX и АТL в том числе. MFC тоже имеется. При наличии более или менее прямых рук (за себя не говорю конечна:)) среда позволяет приручить практически любую либу и/или технологию через написания мастеров. В этом плане IDE реализовано неплохо просто многие этим не пользуются.
MFC - это нечто доисторическое и изначально кривое IMHO.
Кто не согласен - пожалуйста, обоснованные аргументы буду услышать рад я.
У ActiveX я бы сказал несколько другая область.
Кто не согласен - пожалуйста, обоснованные аргументы буду услышать рад я.
ну не услышишь ты их т.к. это еще то г..., суть-то не в этом
У ActiveX я бы сказал несколько другая область.
Область - это Ленинградская например или Московская, а ActiveX - это технология (во всяком случае я так считал или давайте определимся в терминах). Для удобства использования разработана библиотека ATL, которая есть в поставке ВСВ6, что здесь не понятно?
..
Область - это Ленинградская например или Московская, а ActiveX - это технология (во всяком случае я так считал или давайте определимся в терминах). Для удобства использования разработана библиотека ATL, которая есть в поставке ВСВ6, что здесь не понятно?
Ок, давай определимся с сутью. Мой пост был ответом на "А поддержка других популярных технологий присутствует, например ActiveX и АТL в том числе. MFC тоже имеется".
Ты хотел сказать, что MFC - это вместо .NET framework's UI? Я бы сказал, что он мягко говоря сильно проигрывает как библиотека для построения GUI.
Человек спросил - имеется-ли в ВСВ ATL/MFC. Я ответил, что имеется и точка. К чему было выдано заявление - "MFC - это нечто доисторическое и изначально кривое IMHO", я честно не понял (хотя с этим согласен полностью). Тоже касается и странной фразы -"У ActiveX я бы сказал несколько другая область", к чему-бы это? Никто меня не спрашивал про область, спросили - имеется-ли, ответил - да.
Ты хотел сказать, что MFC - это вместо .NET framework's UI? Я бы сказал, что он мягко говоря сильно проигрывает как библиотека для построения GUI.
ну похоже вы не со мной, а с кем-то другим разговариваете...где я такое говорил?
Кто такое спрашивал? Я просто в порядке флейма сравнил список извесных мне популярых подходов (доступных из коробки) к построению десктопных приложений в IDE RAD2009 и VS2008. Конечно, при потребности всякое можно прикрутить к ним, вон - Qt к примеру.
Я тут на днях посмотрел как веб-сервисы на нативных делфях в RAD2009 делаются. Чет кошмарный ужас это после C# с его [WebMethod] и автоматической SOAP-сериализацией. :rolleyes:
З.Ы. Только знающий толк в айтишных извращениях станет MFC к BCB прикручивать.
изначально ты вроде про ВСВ6 толковал и прозвучало это как-то неопределенно, без уверенности можно сказать, поэтому для поддержания флейма я и ответил
З.Ы. Только знающий толк в айтишных извращениях станет MFC к BCB прикручивать.
У меня на этот счет другая теория - если до конца понимаешь, что творишь и руки растут из плеч, то это будет совем другая история
Понятно, что при разработке GUI MFC больше времени сжирает, чем VCL, но все же в чем "кривость"?
Тесная связь с WinAPI возможно + отсутствие кроссплатформенности + мм..не очень хороший вид GUI + модель абстракции предлагаемая слишком низка, опять же из-за связи с WinAPI?
Я не претендую на правоту, поскольку C++ - это вообще не моя специализация.
Но возьми например примеры GUI из Qt последних версий, посмотри структуру и количество кода, нужное для его создания. Сравни с тем, что надо сделать чтобы такой GUI создать на MFC.
Я про это говорю не для того, чтобы заострить внимание на подобранных примерах, наоборот - на уровне абстракции предлагаемой, архитектуры приложений на основе этих библиотек.
Билдером никто не наслажается, это раз. Им пользуются. И не по той причине, которую ты описал, а по причине того, что они, как я помню, вышли первые на широкий рынок с предложениями визуального построения GUI.
Билдером никто не наслажается, это раз.
Говори лучше за себя, два. Я им тоже не наслаждаюсь, не люблю, приходиться юзать, но увидев как от делфи некоторые радостно прыгают, думаю и по билдеру такие найдуться.
Им пользуются. И не по той причине, которую ты описал, а по причине того, что они, как я помню, вышли первые на широкий рынок с предложениями визуального построения GUI.
Смешно то, что ты не уловил суть того, о чём я написал, но это понятно ведь важнее тебе было написать, что ты помнишь тот момент когда он действительно вышел на рынок с революционным гуи и не только.. и тебе после всего что ты видел и юзал, после огромного опыта программирования до билдера, это очень понравилось
Бред. Как модель абстракции может (вообще что ты имелл ввиду, но если я правильно понимаю) может быть слишком низка из-за связи с WInAPI, ты что думаешь другие системмы и та же qt через что то другое работают?? Вид гуи в QT это картинки... рассказывали что если на X терминалах исполняются приложения qt то они ужасно тормозят при копированиии этих картинок по сети, так что привязка к возможностям системмы по крайней мере надёжна. Отсутствие кроссплатформенности, это ты откуда взял? я например одни и те же сппшники в никсах и билдере юзаю, просто писать надо с головой, сам с++ кроссплатформенный, билдер конечно развращает чють чють стандарты.
А если ты это имелл в виду чтобы была кроссплатформенность и вцл классов и гуи - юзай киликс - будут тебе там и те же классы, и гуи через qt, что там они заюзали
А вот что нехорошо это традиционная, привычка делфистов и билдеров)) писать код неразрывно с гуи, оттого и кроссплатформенность страдает и вотэта твоя абстракция никакущая.
[QUOTE=Zorkus;288131]Тесная связь с WinAPI возможно + отсутствие кроссплатформенности + мм..не очень хороший вид GUI + модель абстракции предлагаемая слишком низка, опять же из-за связи с WinAPI?
...
Отсутствие кроссплатформенности, это ты откуда взял? я например одни и те же сппшники в никсах и билдере юзаю, просто писать надо с головой, сам с++ кроссплатформенный, билдер конечно развращает чють чють стандарты.
[/QUOTE]
Ты вообще читаешь на какой вопрос товарищ Zorkus отвечает? Я тебе подскажу - этой цитатой он обосновывает "корявость" MFC. И какая связь между корявостью/прямолинейностью MFC, твоей головой, никсами и Билдером?
А если ты это имелл в виду чтобы была кроссплатформенность и вцл классов и гуи - юзай киликс - будут тебе там и те же классы, и гуи через qt, что там они заюзали
тоже в топку...
А вот что нехорошо это традиционная, привычка делфистов и билдеров)) писать код неразрывно с гуи, оттого и кроссплатформенность страдает и вотэта твоя абстракция никакущая.
с какого перепугу?
ЗЫ: и это как-бы помягче ... пожайлуста на пол тона ниже можно? А то создается впечатление, что ты отвечаешь немного резко (и уже не в первый раз).
так вот. На работе у меня стоял Delphi7, дома писал проект на BDS2009 (и сейчас пишу). Мое мнение, что если переносить готовые проекты - это будет слишком долго и мучительно. Я пробовал. задолбался и плюнул. Но если начинать новые, то однозначно BDS2009 рулит. Что понравилось:
1. Юникод. По любому хорошо :) Объяснять, думаю, смысла нет.
2. Дженерики. Если особо над ними не извращаться, то работают нормально. Может пригодиться в некоторых случаях.
3. Кой какие языковые конструкции - но про них на сайте CodeGear.
Из плюсов самой IDE хочу еще отметить рефакторинг (он вроде как не мегакрутой относительно других продуктов, но все же есть полезные фенечки), гораздо более удобный редактор кода нежели в старых дельфях (я даже не побоюсь сказать что старый редактор по сравнению с новым - блокнот блин). Такс, что же еще... А, кой какие новые компоненты добавили, но это в принципе мелочи ибо не факт, что сильно нужны. Плюс, насколько я слышал от других людей, кто работает с этой средой более активно, она гораздо стабильнее ведет себя на больших проектах. Из минусов заметил один - очень глючный TODO лист. Хз почему, ну и может уже пофиксили, я апдейты не ставил. А так, нравится в принципе. А, и интерфейс удобный, все эти Dockable окошечки радуют глаз. :)
Так что я бы старые проекты в эту среду не переводил, а вот новые начинать - почему бы и нет. Впрочем тут дело вкуса, можно новые и вижуал студии 2008 начинать. Вот так как то...
...
Так что я бы старые проекты в эту среду не переводил, а вот новые начинать - почему бы и нет.
Что бы потом долго и мучительно переводить ее в RAD2012? :) Настоящий момент - момент ФОРМИРОВАНИЯ новых принципов работы технологий и т.д. ТО что тебе кажется сейчас клевой фичей - через годик-два будет возможно тупиковым, мертвым и убогим - а если в компании принято каждую новую среду разработки создавать заново - и наша песня хороша, переписывай 20-30% приложения ради того что бы внести на 5 строк изменений? Оно мне надо? :) (риторичский вопрос). Поэтому вопрос не о том - лучше ли шарп или все же делфи.
Работал с 4 Делфи->5 BCB->2006 BCB->2007 BCB->2009 BCB->2007 BCB.
Стоит заметить, большую глючность ИДЕ и, правильно замечено выше, что до 1го СП делать там нечего. В то же время на BCB можно реализовать любую технологию на АПИ.
Из опыта перехода на след. версию скажу, что переделывать ничего не пришлось. Среда сама всё сконвертировала. Но при переходе на BCB 2007 вылезла более строгая типизация. Я (не знаю почему) люблю писать так (String)Переменная. В 2007 только для int это прокатило. А так проекты плавно перетекли. Использую ДевЭкспресс. Апгрейт ничего не стоил.
А вот на 2009 я не смог перетащить пректы. Все стринги стали Юникодами, обработка их отличается, проекты стали неправильно работать. Остался на 2007.
Пробовал и С#. Пишется легко (мелкие поделки, до больших не дошел). Был удивлен большой схожестью с Делфи.
Но каждому свое. Насильно мил не будешь, да и всегда хочется что то новое.
Еще я вижу + в том, что зная С++ переход на новую версию ИДЕ сохраняет кучу времени на изучение нового языка, новых фич в ИДЕ, и т.д. и т.п.
Спасибо за прочтение!
Просвети пожайлуста, что там (в 2009-й) с лицензией на MIDAS. Надо дополнительно приобретать? Или все включено. Раньше надо было отстегивать и за сервер и за клиентов (есть документик на офсайте, но он староват). Щас прошла информация, что MIDAS/DATASNAP - без лицензионных отчислений.
Веб приложения для учета автомолилей, или чего там.
Скажите, как у вас реализованы страницы?
Когда в приложении скажем, 50 базовых моделей,
[COLOR=black][FONT=Verdana]Не думала, что буду писать больше в этот форум, ибо один из модераторов этого форума просто сноб...[/FONT][/COLOR]
[COLOR=black][FONT=Verdana]Итак, на сегодняшний день, на сервер посылают данные 64 трекера.[/FONT][/COLOR]
[COLOR=black][FONT=Verdana]Технологии: Indy 10, DataSnap, IntraWEB. Все работает...[/FONT][/COLOR]
[COLOR=black][FONT=Verdana]Поскольку все работает, мнения псевдо гуру меня не особо волнуют...[/FONT][/COLOR]
Елена, Вы уже прекратите понты свои показывать и пытаться ущемить "псевдо гуру" и "одного из модераторов"? Таких решений МОРЕ!!! И все работают =) и инновацию вы не совершили (кста, 64 трекера это не так уж и много) =) Успокойтесь. Дышите глубже, платите кредит :)
И кстати, искренне рад за Вас, на тему того, что Ваш продукт кто-то взял и стал использовать, вместо динозавров этой нишы рынка =) Поздравляю
я сам мидас вроде как не юзаю, но почитай вот это:
http://edn.embarcadero.com/article/20870
оно?
это "Раньше...", а я спрашиваю как сейчас:)