Переключение разработчика Delphi на С#

Я довольно долгое время занимаюсь Delphiholic, и в последнее время я тоже подумывал об изучении С#, однако я немного "боюсь неизвестного", я сделал несколько простых приложений в качестве тестового диска для С#, и я должен признать, что мне это понравилось, ОЧЕНЬ мне не очень нравится IDE... что здесь сказано, что я хотел бы, чтобы другие, которые пошли по этому пути, ответили:

Как разработчик Delphi, какие "основные базовые" изменения происходят из языка Delphi (базовыми я имею в виду базовые функции - утилиты, потоки и т.д.), я привык добавлять "System, Classes, Windows" к использует не "использовать System.XXX.YYY.ZZZ", я пытаюсь сделать частичное равенство в своем уме от Delphi до С#, пока не увижу, где Delphi идет рука об руку с С# и так далее...

Я надеюсь, что вопрос будет довольно ясным, если нет, не стесняйтесь клясться, и я попытаюсь уточнить, а также могу: -)

ОТВЕТЫ

Ответ 1

Я использую как для разработки программного обеспечения.

Скорость разработки серверных приложений (веб-приложений, веб-сервисов, служб Windows) намного выше в .NET.

Скорость разработки бизнес-приложений (чистый пользовательский интерфейс Windows) намного выше в Delphi.

Разработка сексуальных приложений - это боль в обеих средах.

Несколько вещей, которые вы должны знать:

  • Изучение платформы .NET потребует много времени: оно огромно, но содержит много штуковин (некоторые драгоценные камни действительно хорошо скрыты).
  • Не теряйте себя, следуя всем новым тенденциям сразу: generics, lambda, LINQ, каждый из них хорош, но схватывать их все сразу только для нескольких из нас
  • Для веб-приложений пропустите WebForms, но изучите ASP.NET MVVC (да, ребята Ruby были в конце концов); выучите HTML 5 и JavaScript тоже.
  • Для сексуальных приложений Windows изучите WPF, но будьте готовы к крутой кривой обучения (дизайнер и каркас радикально отличаются).
  • Не пользуйтесь слишком сексуальным интерфейсом: вам стоит непропорциональное количество времени, пока ваши пользователи ждут функциональности.
  • Подобно тому, как рынок избивает Delphi с версии 1, рынок тоже избивает SilverLight
  • Пропустить WinForms; если вам нужно что-то вроде WinForms, то Delphi будет более продуктивным (тем более, если у вас есть существующая кодовая база Delphi VCL).
  • WPF так же удобен для потоков, как VCL или WinForms (читайте: ни один из 3 не поддерживает поток)
  • Не выполняйте перезаписи вашего материала Delphi в .NET(или, в этом случае, любой другой вариант 1:1 переписывается с платформы A на платформу B): это пустая трата вашего времени.
  • Потоки и синхронизация - это боль во всех средах разработки. Боль не столько в общем материале (Concurrent Collections в среде .NET 4 помогает, как и Delphi OmniThreadLibrary), но при получении окончательных данных и случаев исключения права - настоящая боль.
  • Сбор мусора не означает, что вы не будете утечки памяти: это означает, что вы не будете течь, когда ваше приложение завершится, но пока он работает, утечки сложнее обнаружить (мальчик, мне жаль, что у меня не было памяти FastMM монитор для .NET)

- Йерун

Ответ 2

"Основные основные" изменения заключаются в том, что библиотека .NET является объектно-ориентированной. Например, вместо глобальных строковых функций, которые распространяются между System, SysUtils, StringUtils и т.д., Все они являются просто статическими методами на String. Вместо глобальных функций управления трассировкой они являются статическими методами в классе Path или File. Вместо TextFile/AssignFile/Rewrite вы создаете StreamReader (или просто вызываете статический File.ReadAllLines или ReadAllText, если файл небольшой). Большинство вещей довольно легко обнаруживаются, когда они курят. Есть несколько недостающих вещей; например, в .NET нет метода IncludeTrailingPathDelimiter (хотя вам он обычно не нужен - Path.Combine лучше).

Я предпочел бы пропустить WinForms. Если вы использовали Delphi VCL, WinForms будут знакомы и все же разочаровывают, безумно неадекватно. Они взяли основные идеи из VCL, но никогда не потрудились дать ему малейшую глубину или даже удобство использования. Там нет эквивалента для TAction/TActionList, свойство Dock (эквивалентное Delphi Align) любит скрывать элементы управления друг за другом, пока вы не соберете "Привести к фронту" / "Отправить на задний план", всплывающие подсказки требуют дополнительного компонента в вашей форме, там только крошечная горстка элементов управления, и это просто с моей головы. Потратьте время на изучение WPF; он получил все богатство VCL и многое другое, и вам придется потратить гораздо меньше времени, ударяя головой о стену.

IDE немного привыкает, но мне это гораздо лучше, чем Delphi. Вы должны изучить другой набор нажатий клавиш, но это не имеет большого значения. IDE более отзывчива (ни одна из них не блокируется во время компиляции "фона" ). У него также есть некоторые дополнения для кик-пота - после того, как вы некоторое время использовали ReSharper, вы не пропустите Delphi IDE немного.