Как эффективнее перелезть на VS.NET?

← →
Piter © (2006-07-02 19:11) [0]

Имеется средненький уровень знаний в Delphi, как языке, так и среде. Поскольку D скорее мертва, чем жива (на эту тему предлагаю дискуссию не разводить), имется желание перелезть на MS студию и технологию .NET

Самые основные концепции .NET понятны, библиотеку классов видели на примере VCL, процессорно-независимый код тоже понятно, но никаких деталей не знаю, с C++ знаком ооочень посредственно (на основе, наверное, чтения MSDN), на шарпе вообще никогда ничего не писал.

Что посоветуете? Думаю, Рихтер - тут ожидаемая рекомендация. Универсальная ли она? Или лучше начать с другого, или вообще совсем не так?

← →
Eraser © (2006-07-02 19:17) [1]

> [0] Piter © (02.07.06 19:11)

> Что посоветуете? Думаю, Рихтер - тут ожидаемая рекомендация.
> Универсальная ли она?

именно, книга хорошая.

> с C++ знаком ооочень посредственно (на основе, наверное,
> чтения MSDN), на шарпе вообще никогда ничего не писал.

не C# (да и вообще .NET вцелом) больше на Delphi чем на C++ похож, imho.

Особых проблем возникнуть не должно.

← →
Игорь Шевченко © (2006-07-02 19:25) [2]

Петцольда тоже можно до кучи почитать.

← →
Piter © (2006-07-02 19:56) [3]

Игорь Шевченко © (02.07.06 19:25) [2]
Петцольда тоже можно до кучи почитать

вместе с Рихтером или вместо Рихтера? :)

← →
Джо © (2006-07-02 20:01) [4]

> [3] Piter © (02.07.06 19:56)
> Игорь Шевченко © (02.07.06 19:25) [2]
> Петцольда тоже можно до кучи почитать
>
> вместе с Рихтером или вместо Рихтера? :)

Вместо — не рекоммендую.

← →
[wl] © (2006-07-02 20:33) [5]

мне кажется, что c# похож больше на java, чем на паскаль (синтаксисом), а вообще - больше на C++Builder, чем на Visual C++

← →
Nic © (2006-07-02 20:44) [6]

to Piter © (02.07.06 19:11)

> Поскольку D скорее мертва, чем жива

Очень спорное утверждение. Да, D8 - бяка, D2005 - глючная, но BDS 2006 по отзывам очень даже ничего.
Один преподаватель сказал интересную вещь: "Можно всю жизнь точить мастерство, и так ничего не сделать толком". Смысл метаться есть какой-нибудь? Если умеете писать на одном языке, то освоить другой - дело техники.

← →
Nic © (2006-07-02 20:46) [7]

Кстати, после Delphi C++ привычнее, чем C#.

← →
Piter © (2006-07-02 20:55) [8]

Nic © (02.07.06 20:44) [6]
Если умеете писать на одном языке, то освоить другой - дело техники

дык освоить все равно надо

← →
iZEN © (2006-07-02 21:22) [9]

Надо переходить на Java и UNIX (Linux или FreeBSD). Пока не поздно.
Там уже есть Mono (если хочется писать на C#) и вся Java (J2ME, J2SE, J2EE).

Windows Vista загибается, не родившись. Она не будет использоваться тем же успехом, что и WindowsXP, и не будет популярна в корпоративной сфере из-за проблем с повышенными требованиями к аппаратуре и дороговизны ПО (сама система и офисные пакеты прежде всего).

MS Office 2007 не поддерживает общепринятый ISO-стандарт OpenDocument и не может конвертить документы в принтабле/ридонли формат PDF. Так что про автоматизацию этого чуда нужно сильно подумать.

COM-технология и OLE-автоматизация будут поддерживаться какое-то время для унаследованных продуктов, но на долговременный заработок рассчитывать не придётся, так как средства разработки на платформе MS уже сейчас ориентируются на .Net и изживают из себя COM/OLE-средства разработки.

В ближайшей перспективе нужно изучать сетевые технологии и AJAX прежде все. Рабочее офисное ПО переходит на сервер. На клиенте остаются специфические вещи и универсальный браузер Web-контента.

← →
jack128 © (2006-07-02 21:34) [10]

Piter © (02.07.06 20:55) [8]
дык освоить все равно надо
шарп осваивать не нужно. Язык проще валенка.

← →
IMHO © (2006-07-02 21:47) [11]

> iZEN © (02.07.06 21:22) [9]
> MS Office 2007 не может конвертить документы в принтабле/ридонли
> формат PDF

MS Office и раньше не поддерживал экспорт в PDF (были сторонние плагины). По-моему, Adobe был против этого.

← →
Игорь Шевченко © (2006-07-02 21:49) [12]

iZEN © (02.07.06 21:22) [9]

> Пока не поздно.

А когда будет поздно ?

← →
DrPass © (2006-07-02 22:21) [13]

> Надо переходить на Java и UNIX (Linux или FreeBSD). Пока
> не поздно.

Кстати, шутки-шутками, но действительно в будущем акцент явно сместится в сторону web-приложений, построенных по принципам AJAX или каком-либо преемнике этой технологии

← →
Marser © (2006-07-02 22:29) [14]

> [12] Игорь Шевченко © (02.07.06 21:49)
> iZEN © (02.07.06 21:22) [9]
>
>
> > Пока не поздно.
>
>
> А когда будет поздно ?

Да, мне тоже интересно :-)

← →
Cashmare © (2006-07-02 23:15) [15]

Ну вот, опять... :) Почему подобные вопросы возникают? Очень имхо: пока Альцгеймер с Паркинсонами всякими не посетили - осваивать и изучать все, что под руку попадается! Избыток знаний еще никому не мешал. А что лучше, что хуже... Если сейчас непонятно, время покажет. В школе много чем пичкали (и пичкают), что не пригодилось вообще. Но не помешало, уж точно. Так что, при наличии свободного времени и места в мозгах лучше все осваивать. По своему опыту, так сказать :)

← →
palva © (2006-07-02 23:17) [16]

Лучше не трогать C++, а осваивать C#

← →
Gero © (2006-07-02 23:36) [17]

После Delphi C# учится нечего делать. Достаточно любой книжки для начинающих.

← →
ZeroDivide © (2006-07-03 09:20) [18]

А зачем переходить? Стратегия развития Delphi состоит в том, что код написаный на нем будет работать под всеми новыми появившимися и не появивимися еще технологиями. Ведь самая главная проблема - это не изучение нового языка, это перенос существующего кода под новую платформу. Если вы сейчас выбираете для изучения Microsoft С#, то это значит, что в последствии вам нужно будет переносить свой код под новый С## или C%$@, а если вы выбираете Delphi, то можете быть уверены, что ваш код будет компилиться ВЕЧНО, вне зависимости от того, "куда завтра пойдет" Microsoft или кто еще.

← →
Курдль © (2006-07-03 09:35) [19]

Могу порекомендовать еще одну книжку, которая поможет разобраться в одном из самых непривычных аспектов VS.NET - ADO.NET. Это одноименная книжка Дэвида Сеппы (David Sceppa). Кстати, для меня было весьма сложно после Делфи перейти на ADO.NET, где так много непривычного. Самое сложное для понимания было отсутствие понятия "текущая запись" датасэта.
И меня бесила сложность работы с гридами, когда "текущую" запись надо находить per rectum :)

← →
Медвед (2006-07-03 09:58) [20]

>если вы выбираете Delphi, то можете быть уверены, что ваш код будет компилиться ВЕЧНО
компилится то он может и будет, а вот работать - нет

← →
Курдль © (2006-07-03 10:28) [21]

> Ведь самая главная проблема - это не изучение нового языка,
> это перенос существующего кода под новую платформу.

Это у кого такая "самая главная проблема"? Я-то думал, что основная проблема - это все усложняющиеся проекты, которые приходится делать "с нуля", а не старые изделия, которые надо поддерживать на плаву любыми силами.

← →
DrPass © (2006-07-03 12:51) [22]

> Я-то думал, что основная проблема - это все усложняющиеся
> проекты, которые приходится делать "с нуля"

Только в том редком случае, когда предприятие не было автоматизировано (хотя, по отечественным реалиям, может быть и не редком). У нас, например, практически не бывает проектов "с нуля". И не только у нас - в Microsoft, например, ситуация такая точно :-)

← →
Piter © (2006-07-03 13:24) [23]

Курдль © (03.07.06 9:35) [19]
Это одноименная книжка Дэвида Сеппы (David Sceppa).

а в электронном виде есть?

← →
Piter © (2006-07-03 13:32) [24]

А правильно я понимаю, что в .NET использовать COM нельзя?

← →
Джо © (2006-07-03 13:43) [25]

> [24] Piter © (03.07.06 13:32)
> А правильно я понимаю, что в .NET использовать COM нельзя?

Можно.

← →
Layner © (2006-07-03 15:04) [26]

Я вот понять не могу (простите не понятливого), как на C# писать шароварные программы, ну или просто надо сделать защищенный код от постороних глаз, при наличии таких программ как .NET Reflector, которая открывает любой exe написанный на .Net, и стоит исх. код на любой язык (Dlphi.Net, Basic, C#, IL...). Объясните, хотя бы кратко :)

← →
Игорь Шевченко © (2006-07-03 15:07) [27]

Layner © (03.07.06 15:04) [26]

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

← →
Курдль © (2006-07-03 15:09) [28]

> Я вот понять не могу (простите не понятливого), как на C#
> писать шароварные программы

Не царское это дело :) Вот когда делаешь систему, состоящую из тысяч исходных файлов, копаться в ней никто не станет!

← →
Layner © (2006-07-03 16:36) [29]

К примеру делаешь регистрацию на сайте, и что, как ключ на валидность проверять будешь в программе? Ой не знаю незнаю :) Пока почти все шароварщики сидят на Win32, и врядли пойдут на .Net...

← →
Piter © (2006-07-03 16:38) [30]

Да ну. Вот FLASH - тоже декомпилируемая штука, и ничего, когда надо что-то скрыть - скрывают :)

← →
Eraser © (2006-07-03 16:39) [31]

> [29] Layner © (03.07.06 16:36)

и не потому что код C# легко реконструировать, а потому что .net framework далеко не везде установлен. Выдет виста - поглядим.

← →
SkyRanger © (2006-07-04 01:06) [32]

> [6] Nic © (02.07.06 20:44)

Отсюда мораль - пишем на Дельфи 6 и не пантуемся. В принципе шестой дельфи должно хватать. Если конечно не юзать замудренные компоненты и библиотеки. :)

← →
Marser © (2006-07-04 01:36) [33]

> [32] SkyRanger © (04.07.06 01:06)
> > [6] Nic © (02.07.06 20:44)
>
> Отсюда мораль - пишем на Дельфи 6 и не пантуемся. В принципе
> шестой дельфи должно хватать.

+1 :-)

← →
Gero © (2006-07-04 01:43) [34]

> [32] SkyRanger © (04.07.06 01:06)

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

← →
MeF Dei Corvi © (2006-07-04 02:05) [35]

> как на C# писать шароварные программы

Если человеку надо, то он и Delphi"йскую шаровару дизассемблирует и найдёт, где поправить, чтобы шаровара превратилась во фривару. Теоритически, можно написать обвязку на ams"е, которая будет кодировать/декордировать всё, что необходимо.

← →
Layner © (2006-07-04 09:41) [36]

Теоритически, можно написать обвязку на ams"е, которая будет кодировать/декордировать всё, что необходимо.
Где на асме, в C# ???? Забудь про это :)
Если человеку надо, то он и Delphi"йскую шаровару дизассемблирует и найдёт, где поправить,
Что проще, пользоваться программой .NET Reflector + скомпилировать свое из вытянутых блоков, или пользоваться какими то не читаемыми дизасемблерами, софт-исой, и т.п. плюс знать как все это устроенно.. для масс просто не реально..

← →
Lamer@fools.ua © (2006-07-04 09:58) [37]

>>Layner © (03.07.06 15:04) [26]

Вариант защиты: под .NET можно код генерировать на лету, поскольку компиляторы C# и VB.NET встроены в сам framework (см. System.CodeDom namespace и иже с ним). Причём скомпилировнную сборку (assembly) необязательно размещать на внешнем носителе, а можно компилировать в режиме im-memory и обращаться к типам, находящимся в сборке, сразу же после успешной компиляции.

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

К тому же в .NET можно использовать небезопасный (unsafe) код и обращаться к неуправляемому (unmanaged) коду (в частности к функциям WinAPI, объектам COM/OLE).

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

Работаю на D7. И не вижу объективных причин переходить на что-то друое. Если надо будет - перейду.

> Nic © (04.07.06 10:01) [38]
> Работаю на D7. И не вижу объективных причин переходить на
> что-то друое. Если надо будет - перейду.

Ключевое слово "работаю". Если бы было "работаем", причины бы нашлись.

ну блин, дожили, на сайте по Delphi народ сваливает на студиу. Но видимо по привычке ещё тут обитает :) ПОнятно, конечно, C++ всегда был более предпочтительным для винды, но по мне D7 нравится, работы хватает вроде, перехходить тоже пока не собираюсь. Но посматриваю конечно, чего греха таить, но только для конкретных целей, например задача под разбор XML, или элементы ActiveX пишу.

> C++ всегда был более предпочтительным для винды

Не о С++ речь - он, будучи за уши притянут на .NET-платформу, там же и отомрет :)

> Курдль © (04.07.06 10:18) [39]

Если удастся открыть студию и будет "работаем" и если причины переходить будут, то проблем с освоением не возникнет. Вместо begin будет {, вместо uses будет using и наймспейсы. Язык на самом деле несложный.

> Язык на самом деле несложный.

А я и не говорил, что сложный. Я вообще против "языковой зависимости". И не только я, а все "мировое прогрессивное программерское сообщество" :)
Думаю, тот, кто сможет разработать среду для проектирования на уровне паттернов, определит ближайшее будущее программирования.

Что значит "на уровне паттернов"? Типа нарисовал стопку UML-диаграмм и получай готовый продукт? Я к этому скептически отношусь в том смысле, что всё равно для задания какой-то бизнес-логики в программе необходимо в компутер ввести определённое количество информации. И мне кажется, что ввод этого дела в виде текста (aka исходного кода на языке программирования) удобнее, чем в виде диаграмм. Ну это моё имхо.
А вот за более тесную интеграцию средств моделирования и разработки - так я руками и ногами за. :)

> Ведь самая главная проблема - это не изучение нового языка,
> это перенос существующего кода под новую платформу.

...Я-то думал, что основная проблема - это все усложняющиеся проекты, которые приходится делать "с нуля"...

Ты ошибался

а не старые изделия, которые надо поддерживать на плаву любыми силами.
Речь идет прежде всего о технологиях и наработках, а не о изделиях... если появился CLR, то это не значит, что все остальные технологии куда то пропали. Единственное что изменилось - код стал управляемым. Это тот же самый код, с той же самой функциональностью, только управляемый. Так что "с нуля" писать разумеется не приходится. И как заметил DrPass © (03.07.06 12:51) [22] "И не только у нас - в Microsoft, например, ситуация такая точно :-)"

> Что значит "на уровне паттернов"? Типа нарисовал стопку
> UML-диаграмм и получай готовый продукт?

В идеале - да! :) Кто бы мог представить 20 лет назад, что можно нечто запрограммировать, "набросав на форму компонентов"?!

Однако, в VS уже многие классы приближены к идеологии паттернов: "Адаптер", "Комманд", "Прокси".

> ZeroDivide © (04.07.06 14:27) [45]

Я не готов особо спорить с тем, что поддержка старых изделий важна. А старые наработки и технологии... Не знаю, как у Вас, но у нас в проектах 80% трудозатрат - на проработку концепции автоматизации предметной области. А процесс "архитектура-модель данных-кодирование-тестирование" проблем не вызывает. Технология - это шире. Это опыт ведения переговоров с должностными лицами, взаимодействие с ответственными исполнителями, работа аналитиков по исследованию автоматизируемого бизнеса, планирование и бюджетирование и мн.др, на первый взгляд не относящееся к IT...

> В идеале - да! :) Кто бы мог представить 20 лет назад,
> что можно нечто запрограммировать, "набросав на форму компонентов"?
>
> Однако, в VS уже многие классы приближены к идеологии паттернов:
> "Адаптер", "Комманд", "Прокси".

Ну, паттерны это конечно здорово, но это не панацея и зацикливаться на них не стоит. Даже сама банда четырёх не раз указывает на то, что это только частные решения отдельный задач и собрать всё приложение из них не всегда можно. Кроме того, излишнее увлечение паттернами - это уже общепризнанный антипаттерн :) Так что я оцениваю это дело не с точки зрения, насколько поддерживаются там именно паттерны, а вообще ОО-разработка, что есть несколько более широкое понятие.

> Даже сама банда четырёх не раз указывает на то, что это
> только частные решения отдельный задач и собрать всё приложение
> из них не всегда можно.

Кстати, мне ближе паттерновый подход GRASP, чем GoF. Он более архитектурен или глобален, что ли... Там всего десяток паттернов, но они не являются догмой а лишь определяют критерии, по которым следует делить систему на функциональные модули.

Ну, GRASP и GoF - это совершенно разные вещи. То, о чём ты говорил выше, это скорее именн GoF с их структурными, поведенческими и прочими паттернами. GoF - это в больше степени набо готовых схем, а GRASP - это в больше степени философия. Если интеграция поддержки паттернов в стиле GoF достаточно очевидна, то как вносить поддержку GRASP - это надо ещё разобраться компетентым органам.

> Alkid © (04.07.06 15:38) [49]

Все правильно! Под гипотетическим вариантом "программирования паттернами" я имел в виду GoF. :)
А вот GRASP - это уже методология. И если грамотно подойти, вооружившись последней, да настрогать полезных (а не каких попало) паттернов из первой, - тогда можно значительно упростить процесс автоматизации. Вот это и будет отработанной технологией! Зная, как и какие шаблоны надо создавать для конкретной системы, можно легко отвязаться от реализации. Ведь, к примеру, не составит труда повторить "фабрику классов", созданную однажды на Java и под C++ и под Delphi.

В принципе такое можно было бы организовать следующим образом:
1. Мощный механизм шаблонов.
2. Обширная библиотека паттернов-шаблонов, рождённых из слияния в экстазе GoF и GRASP. Типа STL, но по паттернам.
3. Мощное средство моделирования\визуальной разработки, заточенное на создание проекта в виде модели с кастомизацией всяких там свойств и т.п.

В принципе идея красивая, но чует моё сердце тут эшелоны подводных камней, расложенных в самых неожиданных местах.

> В принципе идея красивая, но чует моё сердце тут эшелоны
> подводных камней, расложенных в самых неожиданных

Какие навскидку шаблоны можно представить себе графически?
Адаптер, контроллер, фабрику...
О! Вспомнил забавный инструмент, не виданный мною ранее и ни на что не похожий - среда разработки процесса интеграции данных "Informatica Power Center". Она позволяет графически спроектировать прохождение потоков данных от "источника" к "приемнику" через "трансформации".
Это я к тому, что идет процесс визуализации проектирования в разных областях IT!

> Язык на самом деле несложный.

Но всё же есть кое-какие нюансы, если верить блогу
http://blogs.msdn.com/ericlippert/

Как эффективнее перелезть на VS.NET? Найти похожие ветки