Привет всем! Давно использую delphi. Начинал с 3-ей версии, на дворе уже 8, 9 версии. Главное отличие этих версии возможность использования платформы .NET. Просто и доступно может мне кто-нибудь объяснить все прелести новой технологии...?

Лично я особых преимуществ перед VCL не вижу,только лишние заморочки

> Просто и доступно может мне кто-нибудь объяснить все прелести
> новой технологии...?

Скажем так, для Delphi-программиста прелести новой технологии неочевидны. Это педантично скопированная Java, щедро сдобренная VCL-подобной библиотекой. Впрочем, для некоторых апологетов Visual С++ она была чуть ли не откровением :) Непонятно только, чем им до .NET тогда не нравился Visual Basic...
Несомненные плюсы - увеличивается надежность программ, уменьшаются требования к квалификации программиста. Несомненные минусы - низкая производительность, высокая ресурсоемкость... И не забыть про гетерогенность. К царящему в нынешних ОС бардаку технологий добавляется еще одна

Так стоит переходить на 8-9 версии delphi или нет?

Стоит почитать книгу Джефри Рихтера "Программирование на платформе Microsoft .Net FrameWork". Там расписано, что такое .NET А вот про остальное на ваше усмотрение,если вас интерисует мое мнение - на .NET стоит обратить внимание, выбор платформы программирования вопрос пока вторичный. Дельфи 2006 коллега очень хвалил -ему понравилось, мне пока хватает и 2003 студии c#.

> Evgeny V ©   (12.06.06 10:34) [4]

Лучьше сразу на .NET 2.0.
Много хороших и нужных фич появилось.

> saxon   (12.06.06 10:42) [5]
> Лучьше сразу на .NET 2.0.
> Много хороших и нужных фич появилось.

Не спорю, много интересного, и многое что упрощается. Но увы производители мобильных терминалов  на которых мы работаем (пишем в основном под мобильные терминалы IRIS, процессор  семейства MIPS) пока не пошли дальше Win CE 4.2 NET, что и вынуждает вводить ограничение на версию FW.

> DrPass ©   (12.06.06 02:20) [2]
> Несомненные минусы - низкая производительность, высокая ресурсоемкость...


Это Вы вспылили от незнания. В перспективе обещается выпуск CLR под конкретный процессор. Причем, допускаются усовершенствования уже существующих версий. Таким образом производительность Вашего ПО будет возрастать без вмешательства в него, а лишь из-за оптимизации среды.

Несомненный плюс VS - это способность поддержки очень крупных проектов. Здесь производительность команды выше в разы, чем при разработке на той же Делфи.
Могу сказать, что поначалу обплевался, при переходе с Делфи на VS 2003. Но теперь не могу себе представить, как бы мы делали несколько последних проектов без VS. Скорее всего - никак.
Делфи мы не забросили, но применяем ее лишь для малых проектов.

А на вопрос "надо ли изучать VS?" легко ответить, походив по сайтам вакансий. Делфи там уже почти не значится :(

> Курдль ©   (20.06.06 10:20) [7]

Почему вспылил? Это факт, до сих пор оспариваемый только на основе рекламных утверждений вроде "в перспективе ожидается..." или "just-in-time компиляция практически устраняет...", и никогда не приводятся цифры тестирований. Или вы утверждаете, что приложения какой-либо виртуальной машины способны работать производительнее своих традиционных аналогов? Что касается CLR под конкретный процессор - тоже не стоит особо на это рассчитывать. Фантастического ускорения это не даст, да и выпускать обновления для .NET1.x и даже .NET2.0 вряд ли кто будет. В лучшем случае - .NET3 в WinVista. Конечно, разработчик всегда сможет "проапгрейдить" свой проект под новую версию фреймворка, но пользователям, у которых программа уже установлена и работает, от этого легче не станет.
А что касается всего остального... ну, надо более трезво смотреть на вещи. Java-истерия в свое время была даже более масштабной. И что с того? Да и .NET-истерия уже потихоньку проходит. Переводить имеющиеся наработки на .NET конкретно нам экономически нецелесообразно.
Кстати, мне совершенно непонятно утверждение
> Несомненный плюс VS - это способность поддержки очень крупных
> проектов. Здесь производительность команды выше в разы,
> чем при разработке на той же Делфи.

В чем же там заключается способность поддержки очень крупных проектов, которой нет в Delphi? Средства коллективной работы Delphi (а также моделирования, управления жизненным циклом приложений) в настоящий момент ничуть не уступают (если не превосходят) свои аналоги.

Хотя насчет вопроса "надо ли изучать VS" я согласен на 100% - надо. Профессионал в любом случае должен уметь использовать наиболее популярные инструменты. А уже с чем он будет работать на практике - жизнь сама определит.

> В чем же там заключается способность поддержки очень крупных проектов, которой нет в Delphi?

Я не имел в виду средства коллективного доступа.
Я имел в виду средства среды разработки.
Хотя многое, что есть в VS удачно подходит для обработки системами контроля версий. В частности, большинство артефактов проекта оформлены в виде текста, XML и прочих форматов, удобных для, например, сравнения и поиска изменений.

То, о чем я говорил:
http://pda.delphimaster.net/?id=1150545629&n=3

> Это факт, до сих пор оспариваемый только на основе рекламных
> утверждений вроде "в перспективе ожидается..." или "just-
> in-time компиляция практически устраняет...", и никогда
> не приводятся цифры тестирований. Или вы утверждаете, что
> приложения какой-либо виртуальной машины способны работать
> производительнее своих традиционных аналогов?


На самом деле бывает быстрее, вот пример: http://atnode.ru/?part=106
Это вычислитель математического выражения, реализован на Delphi и C#. Практически одинаковый код, одинаковая объектная модель. Для измерения времени выполнения проводится 1000 итераций, и показывается среднее время.
Результат на моём компьютере - Delphi 0.17-0.18мс, С# 0.14-0.15мс. Я думаю, .Net выигрывает здесь из-за того, что в Delphi память от использованных объектов освобождается сразу, и на это уходит время, а в .Net сборщик мусора оставляет это на потом.

> Курдль ©   (29.06.06 20:55) [9]

Но ведь Delphi (я не имею в виду древнюю D7) тоже умеет "поддерживать десятки Projects (концептуальные модули, АРМ, сервисы, общие библиотеки, интерфейсы и мн.др.). Причем компилить и билдить все это совместно, с указанием разграничения видимости". Разве что хорошего инсталлятора в штатном комплекте нет. Но поскольку Delphi на создание "коробочных" продуктов и не нацеливается, это не проблема. Инсталляционный XML-скрипт у меня висит там же, в проекте, а утилита, компилирующая по нему дистрибутив, вызывается через меню. Т.е. все так же элементарно.
Что касается "датасетов", в .NET и в Delphi это совершенно разные сущности, и сравнивать их никак нельзя. Модель работы с данными в Delphi требует большего вмешательства программиста, но зато она намного нагляднее представляет структуру данных. При поддержке и развитии проекта это может стать более полезным свойством, нежели умение вызывать пачку SELECT'ов методом DataAdapter.Fill

> Жуков Олег   (29.06.06 23:52) [10]

Интересно, надо будет посмотреть

хех ) посмотрите на LINQ (DLinq / XLinq) и то что ждет нас окромя него в C# 3.0 - это стало для меня последней каплей, чтобы оставить дельфю для поддержки ранее написаных проектов и мелких утилит, которые иногда проще на ней накатать.

> Но ведь Delphi (я не имею в виду древнюю D7) тоже умеет "поддерживать десятки Projects...

Да? Прямо в Solution Explorere, включенном в GUI среды Delphi можно увидеть все проекты одного решения, обозначить их зависимости, сгруппировать файлы проектов в folders, обновить метаданные сборок? Можно ли в Delphi по F9 запустить в нужной последовательности свежеоткомпиллированный сервер приложений, парочку его разнородных клиентов и все это отлаживать в едином дебаггере?


> Модель работы с данными в Delphi требует большего вмешательства
> программиста, но зато она намного нагляднее представляет
> структуру данных.


Ни за фто не соглашусь!

В ADO.NET, как Вы знаете, датасэты многотабличные. Включают в себя метаданные, характерные для РСУБД (таблицы, релэйшны, констрэйнты, ключи). Так VS позволяет строить датасэты прямо в графическом дизайнере, в виде, близком к ER-диаграмме. Т.е. датасэт является копией фрагмента модели БД. О какой еще "бОльшей наглядности" можно говорить?

>>Жуков Олег   (29.06.06 23:52) [10]

Сомневаюсь, что выигрыш в производительности в данном конкретном примере из-за сборщика мусора; слишком мало объектов. К тому же измерение проводится функцией GetTickCount, которая, во-первых, не обеспечивает точность для значений такого порядка ("Delphi 0.17-0.18мс, С# 0.14-0.15мс"), а во-вторых, меряет не совсем то, что надо.

Что точно знаю (проверял), так это то, что JIT компилятор .NET'а использует фичи процессора. Например, наблюдал в disassembly использование MMX регистров для передачи структуры System.Drawing.Point (состоит из 2-х 32-битных целых — итого 64 бита).

> Почему вспылил? Это факт, до сих пор оспариваемый только
> на основе рекламных утверждений вроде "в перспективе ожидается.
> .." или "just-in-time компиляция практически устраняет..
> .", и никогда не приводятся цифры тестирований. Или вы утверждаете,
>  что приложения какой-либо виртуальной машины способны работать
> производительнее своих традиционных аналогов?

Во всяком случае, как геймдевер-любитель могу сказать, что C#(и .NET) проигрывает по скорости выполнения процентов на 15 тому же Си++, результаты относительно Delphi не однозначны. Было такое, что шарп работал даже быстрее Delphi, было, что на равне, было, что и отставал, но не слишком сильно (не более 5-10%). А за счёт скорости разработки под шарпом, лично я про эти десять процентов с лёгкой душой забываю.

P.S. Ждём .NET 3 :) Оптимизатор в .NET, кстати, достаточно умный ;) Обещают ещё умнее и ещё быстрее, да ещё и с фичами под процессор, так что, поживём - увидим.

>Курдль ©   (30.06.06 08:48) [13]
>В ADO.NET, как Вы знаете, датасэты многотабличные.
>Включают в себя метаданные, характерные для РСУБД (таблицы, релэйшны, констрэйнты, ключи).
и спрашивается на хрена все это знать клиенту, который мыслит бизнес-сущностями ? как же независимость от структуры базы ? возврат к толстым клиентам ? нравится бизнес логику в исполняемый файл зашивать ?
плавали, знаем

> и спрашивается на хрена все это знать клиенту, который мыслит
> бизнес-сущностями ?


Я не понял этот набор громких слов.
Если бизнес-сущности умело вписаны в ER-модель, то разница размыта. Тем более, что я не понял, кого называть "клиентом"? ервер приложений по отношению к СУБД тоже клиент, но это не отнимает у него права работы на уровне технических служб (если мы говорим на одном языке). А теперь рассмотрим пример из даже уровня представлений (который я часто привожу).
Представьте себе окно редактированияданных  клиента. На уровне предметной области - это физическое лицо, покупатель. А в БД он представлен четырьмя сущностями - СУБЪЕКТ, АДРЕС, ТЕЛЕФОН, ПАСПОРТ.
Так насколько удобно на этой форме "поместить" датасэт, включающий в себя все эти 4 таблицы и работать с ними, как с целостным фрагментом модели! Сразу контролировать все бизнес-правила хранения данных (типа адреса может быть только 2, паспорта - тоже и т.п.). А при успешном заполнении фиксировать все изменения в базе одним махом.
Какие возражения?

> Так насколько удобно на этой форме "поместить" датасэт,
> включающий в себя все эти 4 таблицы и работать с ними, как
> с целостным фрагментом модели! Сразу контролировать все
> бизнес-правила хранения данных (типа адреса может быть только
> 2, паспорта - тоже и т.п.). А при успешном заполнении фиксировать
> все изменения в базе одним махом.
> Какие возражения?


А не проще оперировать экземпляром класса "физическое лицо", в нем же устраивать проверки, а потом его маппером отправлять в базу данных, раскидывая по нужным таблицам ?

>Какие возражения?
возражения такие, что это будет работать лишь для самых простых примеров, для более сложных сущностей успешно "фиксировать все изменения в базе одним махом" будет гораздо сложнее, ибо сложнее будет бизнес логика
для меня гораздо удобнее правила описывать по возможности на уровне СУБД, которая изначально содержит необходимы для этого средства "характерные для РСУБД (таблицы, релэйшны, констрэйнты, ключи). " - именно по этому мне непонятно зачем переносить это на уровень приложения
я читал книжки и знаю что большинство авторов отводит среднему звену реализацию бизнес-логики, но для меня это фасадный уровень, предоставляющий клиенту нужные интерфейсы, которые скрывают СУБД и в большинстве случаев лишь транслируют вызовы фасадных методов в вызовы хранимых процедур
PS
только не надо про независимость от постащика СУБД ничего говорить, не верю я в это, да и глупо отказываться от возможностей Oracle или MS SQL
про R3 знаю, не аргумент