VS против Delphi

← →
Cherrex © (2005-10-06 14:59) [0]

Здравствуйте господа. Перед не небольшим коллективом прораммистов ставят большую задачу (2 года). Кадача сводится к написанию клиентского приложения под СУБД SYBASE. И тут в коллективе разгорелись споры: Переходить на .NET или нет.
После того как большинство проголосовало за .NET разгорелся спор на чем писати VS (C#) или Delphi .Net. .NET толком не кто не знает из нас. На предприятии есть и то и то, дополнительно закупать не чо не надо.
ВОПРОС: Что использовать VS (C#) или Delphi .Net. Какие приемущества и не достатки у обеех систем?

← →
Андрей Жук © (2005-10-06 16:58) [1]

← →
Sergey_Masloff (2005-10-06 22:20) [2]

Распускать на хрен коллектив в котором такие вопросы голосованием решаются. Просто правление колхоза какое-то. Не шутка...

← →
Джо © (2005-10-07 03:15) [3]

> большинство проголосовало за .NET разгорелся спор

> .NET толком не кто не знает из нас

Забавно-с...

← →
Cherrex © (2005-10-07 08:32) [4]

> Забавно-с...

Но всем Хочится опробывать

← →
Lamer@fools.ua © (2005-10-07 08:34) [5]

>После того как большинство проголосовало за .NET разгорелся спор на чем писати VS (C#) или Delphi .Net. .NET толком не кто не знает из нас.

Русского, похоже, тоже никто не знает?

← →
Lamer@fools.ua © (2005-10-07 08:36) [6]

По сабджу:
Либо C# дотнет, либо Delphi не-дотнет.

← →
DiamondShark © (2005-10-07 12:51) [7]

Главное преимущество VS.NET в том, что у него нет недостатков.
Главный недостаток Delphi.NET в том, что у него нет преимуществ.

← →
Cherrex © (2005-10-07 13:53) [8]

Чем Delphi.NET так плох в реальности. По моему (хотя я скорее всего ошибаюсь) разница в синтаксисе и в производителе. А еще в книги DELPHI FOR .NET написано что Delphi очени сильно повлияло на создание .NET. И много .NET от Делфи ( что именно не знаю).

← →
DiamondShark © (2005-10-07 16:14) [9]

> Чем Delphi.NET так плох в реальности

Он не плох. Мне нечего сказать против него.

Но мне так же нечего сказать и ЗА него.
А это гораздо хуже.

← →
Антон773 (2005-10-08 09:24) [10]

В восьмой делфи глючит ActiveX(winform)

← →
Priest © (2005-10-10 15:39) [11]

>>Cherrex
Delphi очени сильно повлияло на создание .NET. И много .NET от Делфи ( что именно не знаю).

Тем что C# разрабатывал тот, кто и Дельфи.

А я сейчас пишу под Дельфи 2005 на С#. Нравится мне больше чем VS 2003. По крайней мере нет постояного сообщения о том, что библиотека с компонентом заблокирована.....

← →
ilya39 © (2005-10-10 16:44) [12]

> Тем что C# разрабатывал тот, кто и Дельфи.

Напомните имя-фамилию этого товарища пожалуйста

← →
Джо © (2005-10-10 16:51) [13]

> [12] ilya39 © (10.10.05 16:44)

Андерс Хейльсберг известен как создатель компилятора Borland Turbo Pascal и ведущий конструктор технологии Borland Delphi
За время его работы в Microsoft с 1996 года главной его заслугой считается создание языка Cool, позже переименованного в C#

← →
ilya39 © (2005-10-10 16:57) [14]

> [13] Джо © (10.10.05 16:51)

Спасибо.

← →
Seg (2005-10-12 17:35) [15]

А что, собственно требуется от .NET?
Какие ставятся задачи, которые нельзя решить, не используя .NET?

← →
DrPass © (2005-10-12 22:51) [16]

Самое смешное вот что:
> .NET толком не кто не знает из нас.

Как тогда можно браться за серьезный проект на .NET?

← →
Lamer@fools.ua © (2005-10-13 00:30) [17]

>>Seg (12.10.05 17:35) [15]

Вопрос, обычно во времени, а не возможности как таковой.

← →
Курдль © (2005-10-13 11:04) [18]

> DiamondShark © (07.10.05 12:51) [7]
>
> Главное преимущество VS.NET в том, что у него нет недостатков.
>

У него туева хуча недостатков!!! Но все равно он лучше, чем Delphi для больших проектов.

Забавно, что наш небольшой коллективчик именно так и пишет - большие проекты на VS (С#) в том числе под Sybase ASA.
Сейчас одно из решений содержит более 20 проектов.

← →
Lamer@fools.ua © (2005-10-13 11:06) [19]

>>Курдль © (13.10.05 11:04) [18]

>Сейчас одно из решений содержит более 20 проектов.

Wow!

← →
Курдль © (2005-10-13 11:14) [20]

> Seg (12.10.05 17:35) [15]
> А что, собственно требуется от .NET?
> Какие ставятся задачи, которые нельзя решить, не используя
> .NET?

Все можно сделать хоть на ассемблере, хоть на "машкодах". Но наверняка изменится время исполнения проекта.

Не знаю, на чем еще, кроме как на VS можно быстро написать, например, трехзвенку. Работа с .NET ДэйтаСэтами не идет ни в какое сравнение ни с чем (разве что Power Builder немного похож).
.NET Remoting мне вовсе показался волшебным чудом. Когда любые данные любой структуры можно запросто гонять между любыми узлами, не заботясь особо даже о том, в локалке они, или в инете. Например, заполняешь Дэйтасэт с несколькими таблицами данными и передаешь его, как параметр, методу "находящемуся" на другом конце сетки.

← →
Курдль © (2005-10-13 11:18) [21]

> Lamer@fools.ua © (13.10.05 11:06) [19]
> >Сейчас одно из решений содержит более 20 проектов.
> Wow!

Как ни стремились минимизировать его - не получилось.
Если есть один сервер приложений и несколько клиентов (трехзвенка с разделением на типы рабочих мест) - приходится городить специальное разделение на элементы, чтобы минимизировать доступ "к тому, куда доступаться не следует".

← →
Lamer@fools.ua © (2005-10-13 21:47) [22]

>>Курдль © (13.10.05 11:18) [21]

Я смайл забыл поставить. Типа поддеть пытался :o)

>Как ни стремились минимизировать его - не получилось.

Значит одно из двух: либо количество проектов - меньше некуда, либо плохо оптимизировали. Склоняюсь к первому варианту.

>>Курдль © (13.10.05 11:14) [20]

> Когда любые данные любой структуры можно запросто гонять между любыми узлами, не заботясь особо даже о том, в локалке они, или в инете. Например, заполняешь Дэйтасэт с несколькими таблицами данными и передаешь его, как параметр, методу "находящемуся" на другом конце сетки.

Запросто-то запросто. Это мне и самому нравится. Но следует, всё-таки, заботиться о производительности и стараться минимизировать объём передаваемых данных.

← →
Курдль © (2005-10-14 10:18) [23]

> Lamer@fools.ua © (13.10.05 21:47) [22]
> >Как ни стремились минимизировать его - не получилось.
> Значит одно из двух: либо количество проектов - меньше некуда,
> либо плохо оптимизировали. Склоняюсь к первому варианту.

Могу запросто объяснить, откуда ноги растут :)
Автоматизация определенного предприятия. Десяток типов рабочих мест (клиентов) - это уже десяток проектов.
Сервер приложений - еще один. Их взаимодействие - на ремоутинге (wellknown-объекты). Значит общий проект для интерфейсов, общий - для дэйтасетов. Общий - для стандартных типов и констант. Кроме того - базовые классы, разработанные на уровне корпоративных стандартов. Еще проект - Setup. Вот и получается - больше 20. Ради интереса посмотрел - файлов в решении больше 3 000!

← →
Lamer@fools.ua © (2005-10-14 10:40) [24]

>>Курдль © (14.10.05 10:18) [23]

Если Вы решили меня просветить, то зря. Я это, в общем, и так знаю :-)

← →
Курдль © (2005-10-14 10:44) [25]

Да я тут лихорадочно оправдываюсь за невинно убиенное файловое пространство :)

← →
Seg (2005-10-14 17:47) [26]

Десяток типов рабочих мест (клиентов) - это уже десяток проектов.

Раньше это модулями называлось.

← →
Seg (2005-10-14 17:49) [27]

Дэйтасэт с несколькими таблицами данными

Я тут начал изучать C#, но так и не понял, как получить из Датасета строку, на которой стоит курсор в Гриде?

← →
DrPass © (2005-10-17 00:05) [28]

Как-нибудь через BindingContext (не слишком интуитивно, но другого не вижу)
CurrencyManager cm = (CurrencyManager)BindingContext[dataGrid1.DataSource, dataGrid1.DataMember];
DataRowView rw = (DataRowView)cm.Current;
DataRow row = rw.Row;

> Seg (14.10.05 17:49) [27]
> Дэйтасэт с несколькими таблицами данными
> Я тут начал изучать C#, но так и не понял, как получить
> из Датасета строку, на которой стоит курсор в Гриде?

Это самая забавная неразбериха в мозгах при работе с ADO.NET - отсутствие "текущей записи" :)

Кроме способа [28] есть еще и методы самого грида.
Получаешь индекс выбранной строки, а по нему - запись.
(Но надо помнить про грабли для мастер-детальных гридов и деревьев - там все по рекурсии). Если пользоваться только навороченными гридами, как я, то будет нечто типа:

private DataRow GetFocusedRow() { DataRow row = null; DevExpress.XtraGrid.Views.Grid.GridView gv; gv = gcRescActs.KeyboardFocusView as DevExpress.XtraGrid.Views.Grid.GridView; if (gv != null) { row = gv.GetDataRow(gv.FocusedRowHandle); } return row; }

← →
Seg (2005-10-19 11:28) [30]

любые данные любой структуры можно запросто гонять между любыми узлами, не заботясь особо даже о том, в локалке они, или в инете. Например, заполняешь Дэйтасэт с несколькими таблицами данными и передаешь его, как параметр, методу "находящемуся" на другом конце сетки.

Это и есть .NET технология?

← →
Seg (2005-10-19 11:32) [31]

По коду в [29] я понял, что данные беруться все-таки из грида, а не из ДатаСета?

> Seg (19.10.05 11:28) [30]
> любые данные любой структуры можно запросто гонять между
> любыми узлами, не заботясь особо даже о том, в локалке они,
> или в инете. Например, заполняешь Дэйтасэт с несколькими
> таблицами данными и передаешь его, как параметр, методу
> "находящемуся" на другом конце сетки.
>
> Это и есть .NET технология?
>

Это часть концепции .NET Remoting. Она гласит, что любые классы могут быть сериализованы для пересылки между доменами. При этом многие классы сериализуемы по умолчанию (напр. датасэт). Большинству других для этого достаточно префикса [Serializable]. Кроме того, внутренние классы технологии .NET Remoting доступны для разработчика (можно писать свои сериализаторы, реальные прокси удаленных объектов, канальные приемники и т.п. ). Самое распространенное вмешательство - включение собственных кодировщиков, либо стандартных типа PGP).

> Seg (19.10.05 11:32) [31]
>
> По коду в [29] я понял, что данные беруться все-таки из
> грида, а не из ДатаСета?

Данные берутся исключительно из датасэта. В .NET есть поняти е контекста привязки. Т.е. любая форма, любой контрол, грид, кнопка (что угодно) может быть привязано к той или иной таблице датасэта. Причем разные контролы - к разным записям одновременно. Поэтому выбирается текущая строка из привязки конкретного контрола по хэндлеру, индексу и т.п.

← →
Seg (2005-10-19 16:20) [33]

I>любые классы могут быть сериализованы для пересылки между доменами.

А это, извините зачем?
Нельзя эти классы просто почтой отправить и включить в проект?

Данные берутся исключительно из датасэта<

Можно пример кода?

> Seg (19.10.05 16:20) [33]
> I>любые классы могут быть сериализованы для пересылки между
> доменами.
> А это, извините зачем?
> Нельзя эти классы просто почтой отправить и включить в проект?

Прикалываемся? :)

Не для компилляции, а для работы распределенной системы!

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

> Можно пример кода?

Ага!
Он в [29]! :)

row = gv.GetDataRow(gv.FocusedRowHandle);

здесь row, в традиционном понимании, - указатель на область памяти, где содержится вся информация о записи таблицы, к которой "привязано" устройство отображения и на которой (в случае грида) установлен маркер "текущая".

Эту row можно юзать по всем законам класса System.Data.DataRow и все изменения в ней реально отразятся на соотв. записи в наборе данных.

← →
Seg (2005-10-19 16:48) [35]

сервер приложения собирает определенный набор данных от SQL-сервера

А откуда сервер приложений знает, какие данные надо выбрать?

> Seg (19.10.05 16:48) [35]
> А откуда сервер приложений знает, какие данные надо выбрать?

Пока программист его не запрограммирует - он и не знает! :)

Приведу пример.
Клиент запросил карточку юридического лица по ID = 0001
Сервер приложений составил запросы к SQL-серверу на заполнение
таблицы основных реквизитов ЮЛ, таблицы банковских счетов, таблицы заказов и таблицы платежей. Потом все это упаковал в ранее разработанный программистами класс - датасэт по имени, напр. dsSubjectCard и отправил его на клиентсое рабочее место.
А последнее, в свою очередь, открыло ранее разработанный программистами класс - форму отображения карточки Юр.лица, где все контролы отображения так или иначе связаны с таблицами такого же точно датасэта dsSubjectCard

← →
Seg (2005-10-19 17:01) [37]

Так это же обычное выполнение запроса.

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

:(

"Клиент" - это клиентская часть трехзвенки (я ж писал это в "параметрах примера" :)

Т.е. он может подключиться к серверу приложений хоть с того же компа, где сервер, хоть с рядом стоящего, хоть с дргуого конца Земли через тырнет.

Фишка в том, что он "одним потоком" получает упакованные в соотв. с замыслом программиста данные, связанные в соотв. с релэйшнами и проверенные констрэйнтами. Т.е. для программиста достаточно вызвать метод удаланного объекта напр. "scSubjectsServerLogic":
scSubjectsServerLogic.FillSubjectCard(dsSubjectCard1);
В результате этого сервер приложений пробежится по коду этого scSubjectsServerLogic, соберет из БД нужные данные и заполнит ими датасэт.
Данные тут же появятся перед светлыми очами благодарного юзера.

← →
Seg (2005-10-20 11:03) [39]

Оно так и было. Пользователь заходит на сайт, выбирает, что ему нужно, нажимает на кнопку и VB или Java скрипт его обрабатывает и возвращает результат.

Ничего нового здесь нет.

> Seg (20.10.05 11:03) [39]
> Ничего нового здесь нет.

Однозначно! :(
Программист - программирует, а юзер - жмет на кнопки и получает результат. Никто ничего нового и не обещал... кроме изменения сроков выполнения проекта.

VS против Delphi Найти похожие ветки