Здравствуйте, Antoshka, Вы писали:
A>>>Вопрос не в том, что там есть вообще, а в том, есть ли что-то нужное для решения КОНКРЕНТНОЙ задачи в конкретное время. G>>И вы готовы писать Enterprise систему на делфи потому что в нем есть POP3, а в .NET нету? A>Так ведь пишутся И работают. И продаются.
Круто, в чем заслуга делфи?
Я уверен что подобного уровня системы на .NET пишутся проще.
G>>Фреймворки ценятся не способностью решать КОНКРЕНТНЫЕ задачи в конкретное время, а покрытием типовых задач и простотой использования компонент. .NET по этим параметрам на 2 головы выше. A>Всё дело в размере головы. Какие такие несравненные плюсы, окромя WPF (здесь я честно ставлю дельфи жирный минус), есть у .NET для разработки толстого клиента?
Тогда лучше рассмотреть что вообще есть для Enterprise разработки, считаем:
1)ORM — Linq 2 SQL, EF
2)Сервисы WCF — в делфи ничего даже отдаленно похожего нету
3)ADO.NET Data Services
4)IoC контейнер, не в состеве .NET, но есть написанные и поддерживемые MS, с AOP и другими страшными TLA
5)Workflow Foundation — при правильном использовании очень хорошая вещь
6)Библиотеки unit-тестирования, как от MS, так и сторонние. Все отлично интегрируются со студией и build-системами
7)Для интерфейсов — WPF. Даже при использовании WinForms есть Binding и не нужно разделение на Data aware и обычные контролы
8)На .NET можно писать процедуры и функции, которые будут исполняться внутри MS SQL Server
Это уже не говоря о разработки для мобильных устройств и веба. У делфи с этим вообще жопа.
Что вам из этого надо для разработки тостого клиента?
Кроме того .NET — не один язык, а множество. Если хотите, то можете писать на C#, VB, Nemerle, F#.
A>>>И в то же время, были вещи, которые в дельфи лучше было не делать. Инструмент выбирается под задачу. Just Business G>>Задачи обычно гораздо шире, чем получение почты по POP3. Для всех (99.99%) задач .NET подходит гораздо лучше делфи.
A>Задачи ровно те, которые ставит перед командой заказчик. Наши внутренние измышления о задачах заказчику монопенисуальны. Ему важен результат. А вот здесь у .NET нет никакого существенного преимущества перед остальными системами программирования.
Спасибо, поржал.
Если интересно скачайте прокект Dinner Now, система от MS, которая показывает многие возможности в .NET 3.5. Потом посмотрите сможете ли повторить такое на делфи. Хотябы серверную часть.
ЗЫ. При наличии Mono .NET даже частично кроссплатформенно получается.
Здравствуйте, gandjustas, Вы писали:
G>>>И вы готовы писать Enterprise систему на делфи потому что в нем есть POP3, а в .NET нету? A>>Так ведь пишутся И работают. И продаются. G>Круто, в чем заслуга делфи?
В том, что система создана, удовлетворяет заказчика и продаётся. Что не так?
G>Я уверен что подобного уровня системы на .NET пишутся проще.
"Я уверен, что проще" — не катит за аргумент. Факты в студию.
G>Тогда лучше рассмотреть что вообще есть для Enterprise разработки, считаем: G>1)ORM — Linq 2 SQL, EF
Linq — не пришей кобыле хвост. EF не знаю, не смотрел.
G>2)Сервисы WCF — в делфи ничего даже отдаленно похожего нету
Нафига они нужны в двухзвенке: СУБД + толстый клиент?
[лирика] У некоторых наших партнёров-монополистов так были сделаны веб-сервисы, то лучше бы они вообще этого не делали, пользовались бы чистым Http. Даже дотнет не жрал их реализацию, пришлось вместо веб-сервисов делать прямые xml+http-запросы к их системам. [/лирика]
G>3)ADO.NET Data Services
EF не знаю, не смотрел.
G>4)IoC контейнер, не в состеве .NET, но есть написанные и поддерживемые MS, с AOP и другими страшными TLA
я тоже знаю много страшных слов. И что?
G>5)Workflow Foundation — при правильном использовании очень хорошая вещь
А зачем? Где её реальное применение в корпоративных системах массовой обработки данных?
G>6)Библиотеки unit-тестирования, как от MS, так и сторонние. Все отлично интегрируются со студией и build-системами
согласен, удобно. Но можно и без них, особенно если логика в хранимых процедурах.
G>7)Для интерфейсов — WPF. Даже при использовании WinForms есть Binding и не нужно разделение на Data aware и обычные контролы
согласен на все 100%
G>8)На .NET можно писать процедуры и функции, которые будут исполняться внутри MS SQL Server
используем. Здесь, как говорится, by design.
G>Это уже не говоря о разработки для мобильных устройств и веба. У делфи с этим вообще жопа.
А зачем это всё нужно в двузвенных корпоративных системах массовой обработки данных??
G>Что вам из этого надо для разработки тостого клиента?
Ничего
G>Кроме того .NET — не один язык, а множество. Если хотите, то можете писать на C#, VB, Nemerle, F#.
Я плакалъ
A>>Задачи ровно те, которые ставит перед командой заказчик. Наши внутренние измышления о задачах заказчику монопенисуальны. Ему важен результат. А вот здесь у .NET нет никакого существенного преимущества перед остальными системами программирования. G>Спасибо, поржал.
И?
G>Если интересно скачайте прокект Dinner Now, система от MS, которая показывает многие возможности в .NET 3.5. Потом посмотрите сможете ли повторить такое на делфи. Хотябы серверную часть.
Зачем? У меня свои задачи, я их спокойно решаю на дельфи. Если будут задачи, где с нетом проще — буду использовать .NET
G>ЗЫ. При наличии Mono .NET даже частично кроссплатформенно получается.
Не интересует. Даже близко.
Что в итоге? Да, в .NET есть много интересного. Но мало такого, без чего невозможно жить. MS Office тому пример. Уже лет шесть прошло с момента выхода .NET, а флагманский продукт MS не спешит его использовать. А зачем тогда остальным просто так переходить?
Здравствуйте, Antoshka, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>>>И вы готовы писать Enterprise систему на делфи потому что в нем есть POP3, а в .NET нету? A>>>Так ведь пишутся И работают. И продаются. G>>Круто, в чем заслуга делфи? A>В том, что система создана, удовлетворяет заказчика и продаётся. Что не так?
Это никак не заслуга среды\языка и прочих технических факторов.
Это в первую очередь заслуга тех кто продает и пиарит.
Во вторую очередь это заслуга самих программистов.
От языка и платформы тут мало зависит.
G>>Я уверен что подобного уровня системы на .NET пишутся проще. A>"Я уверен, что проще" — не катит за аргумент. Факты в студию.
Преимущества .NET я ужде привел. Если вы не можете или не хотите использовать эти преимущества, это не проблема .NET.
Кроме того на .NET можно вести разработку используя бесплатные инструменты, делфи без платной среды не откомпилируешь даже.
G>>Тогда лучше рассмотреть что вообще есть для Enterprise разработки, считаем: G>>1)ORM — Linq 2 SQL, EF A>Linq — не пришей кобыле хвост. EF не знаю, не смотрел.
Так наверное стоит посмотреть. Что подобное есть в делфи?
G>>2)Сервисы WCF — в делфи ничего даже отдаленно похожего нету A>Нафига они нужны в двухзвенке: СУБД + толстый клиент?
G>>Это уже не говоря о разработки для мобильных устройств и веба. У делфи с этим вообще жопа. A>А зачем это всё нужно в двузвенных корпоративных системах массовой обработки данных??
Я же писал что рассматриваем фичи для Enterprise, в разных программах могут потребоваться разные возможности.
A>[лирика] У некоторых наших партнёров-монополистов так были сделаны веб-сервисы, то лучше бы они вообще этого не делали, пользовались бы чистым Http. Даже дотнет не жрал их реализацию, пришлось вместо веб-сервисов делать прямые xml+http-запросы к их системам. [/лирика]
Это проблема тех кто пишет сервисы.
G>>3)ADO.NET Data Services A>EF не знаю, не смотрел.
G>>4)IoC контейнер, не в состеве .NET, но есть написанные и поддерживемые MS, с AOP и другими страшными TLA A>я тоже знаю много страшных слов. И что?
G>>5)Workflow Foundation — при правильном использовании очень хорошая вещь A>А зачем? Где её реальное применение в корпоративных системах массовой обработки данных?
Наверное стоит посмотреть на все эти технологии перед тем как писать свое мнение.
G>>6)Библиотеки unit-тестирования, как от MS, так и сторонние. Все отлично интегрируются со студией и build-системами A>согласен, удобно. Но можно и без них, особенно если логика в хранимых процедурах.
В database Edition студии можно Unit-тесты для БД писать.
G>>7)Для интерфейсов — WPF. Даже при использовании WinForms есть Binding и не нужно разделение на Data aware и обычные контролы A>согласен на все 100%
G>>8)На .NET можно писать процедуры и функции, которые будут исполняться внутри MS SQL Server A>используем. Здесь, как говорится, by design.
G>>Что вам из этого надо для разработки тостого клиента? A>Ничего
В свете выделенного выше очень интересна последняя фраза.
G>>Кроме того .NET — не один язык, а множество. Если хотите, то можете писать на C#, VB, Nemerle, F#. A>Я плакалъ
И?
G>>Если интересно скачайте прокект Dinner Now, система от MS, которая показывает многие возможности в .NET 3.5. Потом посмотрите сможете ли повторить такое на делфи. Хотябы серверную часть. A>Зачем? У меня свои задачи, я их спокойно решаю на дельфи. Если будут задачи, где с нетом проще — буду использовать .NET
G>>ЗЫ. При наличии Mono .NET даже частично кроссплатформенно получается. A>Не интересует. Даже близко.
, только не в плане языков, а в плане технологий.
Вы смотрите на все технологии через призму задач, которые вами решались в той программе которую пишите. Даже более того, вы еще ограничиваете себя деталями реализации. Поэтому все фичи вам кажутся неужными и бесполезными. При этом вы свое мнение экстраполируете на всю разработку.
A>Что в итоге? Да, в .NET есть много интересного. Но мало такого, без чего невозможно жить.
А какой смысл использовать не самые мощные средства разработки?
Разве что чтобы пиписька длиннее была.
A>MS Office тому пример. Уже лет шесть прошло с момента выхода .NET, а флагманский продукт MS не спешит его использовать.
Да ну?
Офис 2007 отлично хостит внутри себя CLR, а также можно писать расширеня на .NET.
Интероп с самой первой версии был.
A>А зачем тогда остальным просто так переходить?
А зачем не переходить?
Если вы имеете ввиду все переписать на .NET, то этого не стоит делать — невыгодно. А начинать новые проекты имеет смысл на .NET.
Здравствуйте, gandjustas, Вы писали:
A>>>>Так ведь пишутся И работают. И продаются. G>>>Круто, в чем заслуга делфи? A>>В том, что система создана, удовлетворяет заказчика и продаётся. Что не так? G>Это никак не заслуга среды\языка и прочих технических факторов. G>Это в первую очередь заслуга тех кто продает и пиарит. G>Во вторую очередь это заслуга самих программистов. G>От языка и платформы тут мало зависит.
Я и говорил, что инструмент — он вторичен.
A>>"Я уверен, что проще" — не катит за аргумент. Факты в студию. G>Преимущества .NET я ужде привел. Если вы не можете или не хотите использовать эти преимущества, это не проблема .NET. G>Кроме того на .NET можно вести разработку используя бесплатные инструменты, делфи без платной среды не откомпилируешь даже.
G>>>Тогда лучше рассмотреть что вообще есть для Enterprise разработки, считаем: G>>>1)ORM — Linq 2 SQL, EF A>>Linq — не пришей кобыле хвост. EF не знаю, не смотрел. G>Так наверное стоит посмотреть. Что подобное есть в делфи?
Наверное стоит, да вот смотреть особо негде. Реальных примеров нет. А hello world'ами я уже сыт по горло.
G>>>Это уже не говоря о разработки для мобильных устройств и веба. У делфи с этим вообще жопа. A>>А зачем это всё нужно в двузвенных корпоративных системах массовой обработки данных?? G>Я же писал что рассматриваем фичи для Enterprise, в разных программах могут потребоваться разные возможности.
Согласен. Но! Часто в этот класс суют задачи, не имеющие отнешения к Enterprise как таковому. А те, которые действительно касаются предприятий и бизнеса, они и без всего перечисленного неплохо решаются.
A>>[лирика] У некоторых наших партнёров-монополистов так были сделаны веб-сервисы, то лучше бы они вообще этого не делали, пользовались бы чистым Http. Даже дотнет не жрал их реализацию, пришлось вместо веб-сервисов делать прямые xml+http-запросы к их системам. [/лирика] G>Это проблема тех кто пишет сервисы.
К сожалению, это проблема тех, кто их использует.
G>>>3)ADO.NET Data Services G>>>4)IoC контейнер, не в состеве .NET, но есть написанные и поддерживемые MS, с AOP и другими страшными TLA G>>>5)Workflow Foundation — при правильном использовании очень хорошая вещь A>>А зачем? Где её реальное применение в корпоративных системах массовой обработки данных? G>Наверное стоит посмотреть на все эти технологии перед тем как писать свое мнение.
Некогда. Т.е., я бы рад их посмотреть. Но, как говорится "в деле". Ради этого даже время бы нашёл. Примеры из MSDN — как-то неубедительно.
G>>>6)Библиотеки unit-тестирования, как от MS, так и сторонние. Все отлично интегрируются со студией и build-системами A>>согласен, удобно. Но можно и без них, особенно если логика в хранимых процедурах. G>В database Edition студии можно Unit-тесты для БД писать.
Цену огласите всех нужных редакций студии.
G>>>7)Для интерфейсов — WPF. Даже при использовании WinForms есть Binding и не нужно разделение на Data aware и обычные контролы A>>согласен на все 100% G>>>8)На .NET можно писать процедуры и функции, которые будут исполняться внутри MS SQL Server A>>используем. Здесь, как говорится, by design. G>>>Что вам из этого надо для разработки тостого клиента? A>>Ничего G>В свете выделенного выше очень интересна последняя фраза.
Ничто не мешает это делать на дельфи. Для CLR-объектов MSSQL можно юзать бесплатный .NET.
G>>>Кроме того .NET — не один язык, а множество. Если хотите, то можете писать на C#, VB, Nemerle, F#. A>>Я плакалъ G>И?
Какие глобальные отличия C# от VB, чтобы считать это мультиязыковостью? Остальное, похоже, из лабораторной практики ещё не вышло.
G>>>ЗЫ. При наличии Mono .NET даже частично кроссплатформенно получается. A>>Не интересует. Даже близко.
G>Вы демонстрируете потрясающий пример парадокса Блаба
Не спорю
G>Вы смотрите на все технологии через призму задач, которые вами решались в той программе которую пишите. Даже более того, вы еще ограничиваете себя деталями реализации. Поэтому все фичи вам кажутся неужными и бесполезными. При этом вы свое мнение экстраполируете на всю разработку.
Если смотреть на всю разработку, то всем языкам до c/c++ как до Луны. Естественно, я смотрю только свою разработку, и разработку своих соседей. За всех пусть говорят маркетологи и им подобные пустомели.
A>>Что в итоге? Да, в .NET есть много интересного. Но мало такого, без чего невозможно жить. G>А какой смысл использовать не самые мощные средства разработки? G>Разве что чтобы пиписька длиннее была.
Да хотя бы в цене и в тоннах унаследованного кода.
A>>MS Office тому пример. Уже лет шесть прошло с момента выхода .NET, а флагманский продукт MS не спешит его использовать. G>Да ну? G>Офис 2007 отлично хостит внутри себя CLR, а также можно писать расширеня на .NET. G>Интероп с самой первой версии был.
Вот когда он целиком от А до Я будет написан на .NET, тогда я поверю, что это .NET-продукт. Хосты и интеропы — это костыли, удобные в некоторых случаях.
A>>А зачем тогда остальным просто так переходить? G>А зачем не переходить? G>Если вы имеете ввиду все переписать на .NET, то этого не стоит делать — невыгодно. А начинать новые проекты имеет смысл на .NET.
Согласен. Но не везде есть новые проекты. Гораздо чаще суппорт или создание новой версии на основе предыдущих.
Здравствуйте, Antoshka, Вы писали:
G>>>>Тогда лучше рассмотреть что вообще есть для Enterprise разработки, считаем: G>>>>1)ORM — Linq 2 SQL, EF A>>>Linq — не пришей кобыле хвост. EF не знаю, не смотрел. G>>Так наверное стоит посмотреть. Что подобное есть в делфи? A>Наверное стоит, да вот смотреть особо негде. Реальных примеров нет. А hello world'ами я уже сыт по горло.
Гугл.
A>>>[лирика] У некоторых наших партнёров-монополистов так были сделаны веб-сервисы, то лучше бы они вообще этого не делали, пользовались бы чистым Http. Даже дотнет не жрал их реализацию, пришлось вместо веб-сервисов делать прямые xml+http-запросы к их системам. [/лирика] G>>Это проблема тех кто пишет сервисы. A>К сожалению, это проблема тех, кто их использует.
нет, как раз тех кто пишет.
Вы можете написать свой сервис на известном только вам протоколе, это будут ваши проблемы.
G>>>>3)ADO.NET Data Services G>>>>4)IoC контейнер, не в состеве .NET, но есть написанные и поддерживемые MS, с AOP и другими страшными TLA G>>>>5)Workflow Foundation — при правильном использовании очень хорошая вещь A>>>А зачем? Где её реальное применение в корпоративных системах массовой обработки данных? G>>Наверное стоит посмотреть на все эти технологии перед тем как писать свое мнение. A>Некогда. Т.е., я бы рад их посмотреть. Но, как говорится "в деле". Ради этого даже время бы нашёл. Примеры из MSDN — как-то неубедительно.
Гугл.
G>>>>6)Библиотеки unit-тестирования, как от MS, так и сторонние. Все отлично интегрируются со студией и build-системами A>>>согласен, удобно. Но можно и без них, особенно если логика в хранимых процедурах. G>>В database Edition студии можно Unit-тесты для БД писать. A>Цену огласите всех нужных редакций студии.
Примерно как две делфи Enterprise.
G>>>>Кроме того .NET — не один язык, а множество. Если хотите, то можете писать на C#, VB, Nemerle, F#. A>>>Я плакалъ G>>И?
A>Какие глобальные отличия C# от VB, чтобы считать это мультиязыковостью? Остальное, похоже, из лабораторной практики ещё не вышло.
Гугл.
Можно еще вспомнить про поддержку динамических языков.
G>>>>ЗЫ. При наличии Mono .NET даже частично кроссплатформенно получается. A>>>Не интересует. Даже близко. G>>Вы демонстрируете потрясающий пример парадокса Блаба
, только не в плане языков, а в плане технологий. A>Не спорю
Так о чем тогда спор?
Я верю что лично вы можете написать на дефли хорошую программу. Также я знаю что на .NET такую же программу можно написать проще.
G>>Вы смотрите на все технологии через призму задач, которые вами решались в той программе которую пишите. Даже более того, вы еще ограничиваете себя деталями реализации. Поэтому все фичи вам кажутся неужными и бесполезными. При этом вы свое мнение экстраполируете на всю разработку. A>Если смотреть на всю разработку, то всем языкам до c/c++ как до Луны. Естественно, я смотрю только свою разработку, и разработку своих соседей. За всех пусть говорят маркетологи и им подобные пустомели. А что же вы на c/c++ не пишите?
A>>>Что в итоге? Да, в .NET есть много интересного. Но мало такого, без чего невозможно жить. G>>А какой смысл использовать не самые мощные средства разработки? G>>Разве что чтобы пиписька длиннее была. A>Да хотя бы в цене и в тоннах унаследованного кода.
В цене чего? На .NET разработка дешевле чем на делфи, вплоть до того что на .NET можно писать используя бесплатные инструменты.
Что касается унаследованного кода, то это называет поддержкой. Я говорю только о разработке.
A>>>MS Office тому пример. Уже лет шесть прошло с момента выхода .NET, а флагманский продукт MS не спешит его использовать. G>>Да ну? G>>Офис 2007 отлично хостит внутри себя CLR, а также можно писать расширеня на .NET. G>>Интероп с самой первой версии был. A>Вот когда он целиком от А до Я будет написан на .NET, тогда я поверю, что это .NET-продукт. Хосты и интеропы — это костыли, удобные в некоторых случаях. А как же тонны унаследованного кода и цена?
Думаете каждая новая версия с нуля пишется?
, только не в плане языков, а в плане технологий. A>>Не спорю G>Так о чем тогда спор? G>Я верю что лично вы можете написать на дефли хорошую программу. Также я знаю что на .NET такую же программу можно написать проще.
Так флейм же изначально. Про лучше никаких аргументов особых не прозвучало. (Названия технологий и т.п. — не в счёт). Вот если бы сказал, что две команды: А и Б — решали одинаковую задачу на разных системах. И достигли таких-то успехов, за такое-то время при оговоренном качестве. Тады ой. А так...
Ну да ладно, я не против .NET, сам на нём пишу кое-какие небольшние проекты. Просто там, где сейчас работаю, приходится работать над большим проектом, который на Дельфи. И там, оказывается, тоже всё можно. С другой стороны, хочется уже перейти на .NET, уж очень там некоторые вещи привлекают (где-то в самом конце треда о писал).
, только не в плане языков, а в плане технологий. A>>>Не спорю G>>Так о чем тогда спор? G>>Я верю что лично вы можете написать на дефли хорошую программу. Также я знаю что на .NET такую же программу можно написать проще.
A>Так флейм же изначально. Про лучше никаких аргументов особых не прозвучало. (Названия технологий и т.п. — не в счёт). Вот если бы сказал, что две команды: А и Б — решали одинаковую задачу на разных системах. И достигли таких-то успехов, за такое-то время при оговоренном качестве. Тады ой. А так...
Да нигде таких данных не будет, дороговатый эксперимент получится.
Я писал программы на делфи и на C#. С появлением .NET 3.5 я понял что массу кода на делфи можно переписать относительно компактным кодом на C#. Что впоследствии и сделал на небольшой программе.
A>Ну да ладно, я не против .NET, сам на нём пишу кое-какие небольшние проекты. Просто там, где сейчас работаю, приходится работать над большим проектом, который на Дельфи. И там, оказывается, тоже всё можно. С другой стороны, хочется уже перейти на .NET, уж очень там некоторые вещи привлекают (где-то в самом конце треда о писал).
Там много чего нельзя. Но вы с этим не сталкиваетесть, потому что никому в голову не придет делать на делфи что нельзя сделать на нем.
Вот почему на делфи до сих пор нет ORM или IoC контейнеров?
ЗЫ. Под словом "нельзя" я понимаю "ооооооооочень долго и дорого".
A>>Ну да ладно, я не против .NET, сам на нём пишу кое-какие небольшние проекты. Просто там, где сейчас работаю, приходится работать над большим проектом, который на Дельфи. И там, оказывается, тоже всё можно. С другой стороны, хочется уже перейти на .NET, уж очень там некоторые вещи привлекают (где-то в самом конце треда о писал). G>Там много чего нельзя. Но вы с этим не сталкиваетесть, потому что никому в голову не придет делать на делфи что нельзя сделать на нем. G>Вот почему на делфи до сих пор нет ORM или IoC контейнеров?
Да бог с ним с IoC, куда серьезнее стоит вопрос утечек памяти в программах на делфи. Если в C++ есть мощные средства типа boost::shared_ptr<>, то в Делфи полный ахтунг — шаром покати...
Вообще это даже смешно сравнивать убогое детище борланд с C#.
Здравствуйте, Antoshka, Вы писали:
A>Ну да ладно, я не против .NET, сам на нём пишу кое-какие небольшние проекты. Просто там, где сейчас работаю, приходится работать над большим проектом, который на Дельфи.
И на сколько же он большой ваш большой проект на Delphi? Можно точную цифру?
Здравствуйте, Antoshka, Вы писали:
G>>Я уверен что подобного уровня системы на .NET пишутся проще.
A>"Я уверен, что проще" — не катит за аргумент. Факты в студию.
Вот тебе факты: ASP.NET MVC/Castle Monorail/Spring.NET MVC, WCF, nHibernate/EF, MEF, Castle Windsor/StructureMap/Unity/Spring.NET, nServiceBus, mbUnit+Rhino Mocks+nCover и т.д. и т.д.
Ну и конечно же средства для automated continous integration, которые разработчикам Delphi не доступны как класс.
Сравнивать Delphi и .NET и особенно на поприще enterprise систем это все-равно что сравнивать Запорожец и Mercedes S-500.. ну да, и то и то едет
G>>Тогда лучше рассмотреть что вообще есть для Enterprise разработки, считаем: G>>1)ORM — Linq 2 SQL, EF
A>Linq — не пришей кобыле хвост.
Так и запишем: не видел, но мнение имеет.
A>EF не знаю, не смотрел.
Кто бы сомневался.
G>>2)Сервисы WCF — в делфи ничего даже отдаленно похожего нету
A>Нафига они нужны в двухзвенке: СУБД + толстый клиент?
Значит ты не видел настоящих enterprise систем, где клиенты могут быть за сотни и тысячи километров от центра.
"Кто бы сомневался".
A>[лирика] У некоторых наших партнёров-монополистов так были сделаны веб-сервисы, то лучше бы они вообще этого не делали, пользовались бы чистым Http. Даже дотнет не жрал их реализацию, пришлось вместо веб-сервисов делать прямые xml+http-запросы к их системам. [/лирика]
Не удивительно... с такими-то программистами. ;]
G>>3)ADO.NET Data Services
A>EF не знаю, не смотрел.
ADO.NET DS это далеко не только EF.
G>>4)IoC контейнер, не в состеве .NET, но есть написанные и поддерживемые MS, с AOP и другими страшными TLA
A>я тоже знаю много страшных слов. И что?
Какие еще страшные слова? Это будни .NET. Ну ладно IoC — его в неуправляемой среде фиг построишь нормальный, но про AOP вообще-то грех не знать. Бегом доучиваться!
G>>6)Библиотеки unit-тестирования, как от MS, так и сторонние. Все отлично интегрируются со студией и build-системами
A>согласен, удобно. Но можно и без них, особенно если логика в хранимых процедурах.
Логика в хранимых процедурах. Добро пожаловать назад в 90-ые...
G>>Кроме того .NET — не один язык, а множество. Если хотите, то можете писать на C#, VB, Nemerle, F#.
A>Я плакалъ
По поводу чего плакал-то?
Ну как перепиши данный простейший код на Delphi:
Async.Run
(Async.Parallel [ AsyncHttp "http://www.live.com";
AsyncHttp "http://www.google.com";
AsyncHttp "http://maps.live.com";
AsyncHttp "http://maps.google.com"; ])
let AsyncHttp(url:string) =
async { do printfn "Created web request for %s" url
// Create the web request objectlet req = WebRequest.Create(url)
do printfn "Getting response for %s" url
// Get the response, asynchronouslylet! rsp = req.GetResponseAsync()
do printfn "Reading response for %s" url
// Grab the response stream and a reader. Clean up when we're done
use stream = rsp.GetResponseStream()
use reader = new System.IO.StreamReader(stream)
// synchronous read-to-endreturn reader.ReadToEnd() }
A>>>Задачи ровно те, которые ставит перед командой заказчик. Наши внутренние измышления о задачах заказчику монопенисуальны. Ему важен результат. А вот здесь у .NET нет никакого существенного преимущества перед остальными системами программирования. G>>Спасибо, поржал.
+1 A>И?
Ты конечно не знаешь про фактор "человеко-часы".
G>>Если интересно скачайте прокект Dinner Now, система от MS, которая показывает многие возможности в .NET 3.5. Потом посмотрите сможете ли повторить такое на делфи. Хотябы серверную часть.
A>Зачем? У меня свои задачи, я их спокойно решаю на дельфи. Если будут задачи, где с нетом проще — буду использовать .NET
Откуда ты знаешь как они решаются на .NET если ты ровным счетом ничего не знаешь о .NET?
Добавлю свои пять копеек.
Сделал простую програмку на Delphi2009 и C# 2008, суть проста
взять Grid и заполнить его строками в количестве N, где N=30000 и 600000
попробовал все три значения. Время мерял через два DateTimePicker, как видно из кода.
В Delphi взял StringGrid, в VS2008 Express — DataGridView.
procedure TSDIAppForm.Button1Click(Sender: TObject);
var
s: TStringList;
I,J,K: Integer;
tm : TDateTime;
begin
s := TStringList.Create;
s.Add('1');
s.Add('ghjikj');
s.Add('прошло');
s.Add('три');
s.Add('года');
s.Add('ывафыва');
s.Add('бздын');
StringGrid1.RowCount := 600000;
StringGrid1.ColCount := 7;
DateTimePicker1.DateTime := Time();
with StringGrid1 do
for J:= 0 to RowCount - 1 do
begin
s[0] := IntToStr(J);
Rows[J].AddStrings(s);
end;
DateTimePicker2.DateTime := Time();
end;
Результаты такие:
на 30000: С# около 73сек. Delphi около 1сек
на 600000: С# не дождался окончания вывода на экран, Delphi — около 15сек.
проверял на виртуальной машине в VirtualBox.
По поводу скорости очевидно.
Выбираю среду разработки для своего проекта, пока что в раздумьях.
Здравствуйте, pers79, Вы писали:
P>Результаты такие: P> на 30000: С# около 73сек. Delphi около 1сек P>на 600000: С# не дождался окончания вывода на экран, Delphi — около 15сек. P>проверял на виртуальной машине в VirtualBox.
Где бы еще найти пользователя, который сможет обработать хотябы 10000 записей в одном гриде.
Здравствуйте, pers79, Вы писали:
P>Добавлю свои пять копеек. P>Сделал простую програмку на Delphi2009 и C# 2008, суть проста P>взять Grid и заполнить его строками в количестве N, где N=30000 и 600000 P>попробовал все три значения. Время мерял через два DateTimePicker, как видно из кода. P>В Delphi взял StringGrid, в VS2008 Express — DataGridView.
P>Код получился такой:
Код получился далеко не эквивалентный. Код на Delphi сразу задает емкость грида, а на дотнете добавляет по одной.
P>По поводу скорости очевидно. P>Выбираю среду разработки для своего проекта, пока что в раздумьях.
Очевидно, что недорос даже до формоклепателя, куда там свой проект
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, pers79, Вы писали:
P>>Результаты такие: P>> на 30000: С# около 73сек. Delphi около 1сек P>>на 600000: С# не дождался окончания вывода на экран, Delphi — около 15сек. P>>проверял на виртуальной машине в VirtualBox. G>
G>Где бы еще найти пользователя, который сможет обработать хотя бы 10000 записей в одном гриде.
Понятно, что тест мой преувеличен. Но скорость меньше, плюс я никакой обработки данных не проводил,
а если с обработкой, то скорость окажется поменьше.
Вообще с такой проблемой я столкнулся, когда писал маленькую програмку, которая запрашивает данные из базы данных,
причем всего лишь из одной таблицы, выводит на печать или сохраняет в файл. Условия выборки: начальная дата-время, конечная дата время, источник, тип события. Решил я написать ее побыстрее, а потому выбор мой пал на Visual Studio 2005 (она тогда была под рукой, а с Delphi я вообще мало знаком).
Написал, да не подумал что в таблице объем может быть большой (время хранения полгода), тем более если интервал выборки сделать как раз полгода. В итоге время отрисовки Grid, при интервале равном полгода показалось мне каким-то долгим, с учетом что компьютер и так был не быстр (на нем два OPC Servera + SCADA система),переписал все на MFC(стало очень шустренько).
Понятное дело, такую проблему обойти не сложно, ужесточить условия выборки, например выводить в интервале не превышающем 3х дней. Но факт, есть факт — скорость меньше.
Кстати с 10000 я тоже пробовал: C# — 5-6 сек., Delphi — меньше 1сек.
Собственно камень ни в чей огород бросить не хочу, нравится и то, и то. Вопрос, что выбрать.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, pers79, Вы писали:
P>>Добавлю свои пять копеек. P>>Сделал простую програмку на Delphi2009 и C# 2008, суть проста P>>взять Grid и заполнить его строками в количестве N, где N=30000 и 600000 P>>попробовал все три значения. Время мерял через два DateTimePicker, как видно из кода. P>>В Delphi взял StringGrid, в VS2008 Express — DataGridView.
P>>Код получился такой: S>Код получился далеко не эквивалентный. Код на Delphi сразу задает емкость грида, а на дотнете добавляет по одной.
P>>По поводу скорости очевидно. P>>Выбираю среду разработки для своего проекта, пока что в раздумьях.
S>Очевидно, что недорос даже до формоклепателя, куда там свой проект
Ну дак расскажи свой вариант, раз уж так все очевидно. Возможно я свой выбор сделаю быстрее, спасибо тебе скажу.
Здравствуйте, pers79, Вы писали:
P>Вообще с такой проблемой я столкнулся, когда писал маленькую програмку, которая запрашивает данные из базы данных, P>причем всего лишь из одной таблицы, выводит на печать или сохраняет в файл. Условия выборки: начальная дата-время, конечная дата время, источник, тип события. Решил я написать ее побыстрее, а потому выбор мой пал на Visual Studio 2005 (она тогда была под рукой, а с Delphi я вообще мало знаком). P>Написал, да не подумал что в таблице объем может быть большой (время хранения полгода), тем более если интервал выборки сделать как раз полгода. В итоге время отрисовки Grid, при интервале равном полгода показалось мне каким-то долгим, с учетом что компьютер и так был не быстр (на нем два OPC Servera + SCADA система),переписал все на MFC(стало очень шустренько).
Так вам надо было в файл записи скинуть или в грид вывести?
Если в файл (как написано выше), то зачем было в грид выводить?
P>Понятное дело, такую проблему обойти не сложно, ужесточить условия выборки, например выводить в интервале не превышающем 3х дней. Но факт, есть факт — скорость меньше.
Скорость чего? Вывода тысячи записей? А кому столько записей в гриде надо?
Пока не начали писать программу запомните простую вещь: не выводите в интерфейс данных больше, чем сможет обработать человек. Для обычного грида это не более пары сотен записей.
Здравствуйте, pers79, Вы писали:
P>Ну дак расскажи свой вариант, раз уж так все очевидно. Возможно я свой выбор сделаю быстрее, спасибо тебе скажу.
Чтобы код для сравнения наполнения гридов получился примерно эквивалентный, нужно для версии C# предварительно установить свойство RowCount у DataGridView.
А лучше воспользоваться свойством DataSource, подсунув туда список строк или DataTable, или что другое.
Ну и кроме того, скорость заполнения грида не является критерием выбора среды.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, pers79, Вы писали:
P>>Вообще с такой проблемой я столкнулся, когда писал маленькую програмку, которая запрашивает данные из базы данных, P>>причем всего лишь из одной таблицы, выводит на печать или сохраняет в файл. Условия выборки: начальная дата-время, конечная дата время, источник, тип события. Решил я написать ее побыстрее, а потому выбор мой пал на Visual Studio 2005 (она тогда была под рукой, а с Delphi я вообще мало знаком). P>>Написал, да не подумал что в таблице объем может быть большой (время хранения полгода), тем более если интервал выборки сделать как раз полгода. В итоге время отрисовки Grid, при интервале равном полгода показалось мне каким-то долгим, с учетом что компьютер и так был не быстр (на нем два OPC Servera + SCADA система),переписал все на MFC(стало очень шустренько). G>Так вам надо было в файл записи скинуть или в грид вывести? G>Если в файл (как написано выше), то зачем было в грид выводить?
P>>Понятное дело, такую проблему обойти не сложно, ужесточить условия выборки, например выводить в интервале не превышающем 3х дней. Но факт, есть факт — скорость меньше. G>Скорость чего? Вывода тысячи записей? А кому столько записей в гриде надо?
G>Пока не начали писать программу запомните простую вещь: не выводите в интерфейс данных больше, чем сможет обработать человек. Для обычного грида это не более пары сотен записей.
В Grid тоже надо выводить было.
Пока не начали писать программу запомните простую вещь: не выводите в интерфейс данных больше, чем сможет обработать человек. Для обычного грида это не более пары сотен записей.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, pers79, Вы писали:
P>>Ну дак расскажи свой вариант, раз уж так все очевидно. Возможно я свой выбор сделаю быстрее, спасибо тебе скажу. S>Чтобы код для сравнения наполнения гридов получился примерно эквивалентный, нужно для версии C# предварительно установить свойство RowCount у DataGridView.
S>А лучше воспользоваться свойством DataSource, подсунув туда список строк или DataTable, или что другое.
S>Ну и кроме того, скорость заполнения грида не является критерием выбора среды.
Ох ни в коем случае не собирался я выбор основывать на скорости заполнения грида. Просто это первая мысль, которая пришла. Попробовал поставить RowCount, попробовал не на виртуальной машине, а на реально машине с 2Гб памяти — все довольно шустро заработало, правда все равно медленнее чем, если б было скомпилировано в обычный exe, но это уже история не о 'vs Delphi'.
Здравствуйте, pers79, Вы писали:
P>Ох ни в коем случае не собирался я выбор основывать на скорости заполнения грида. Просто это первая мысль, которая пришла. Попробовал поставить RowCount, попробовал не на виртуальной машине, а на реально машине с 2Гб памяти — все довольно шустро заработало, правда все равно медленнее чем, если б было скомпилировано в обычный exe, но это уже история не о 'vs Delphi'.
Т.е. ты на глазок прикинул время JIT компиляции для такой маленькой сборки? Ну и на сколько медленнее оказалось, чем если б было скомпилировано в обычный exe?
P>За совет спасибо.
То был не совет, а исправление вкравшегося недоразумения, дискредитирующего дотнетовский грид
Если не сложно, приведи новые цифры. Мне просто интересно, а вопрос о выборе платформы для меня пока не стоит.
И работают. И продаются.
Понятно, что тест мой преувеличен. Но скорость меньше, плюс я никакой обработки данных не проводил, 
