Что .NET дает мне, что Win32 НЕ?
Каким будет использование .NET для меня, чтобы у меня не было использования Win32 - а иногда, может быть, googling для 50-100 строк кода, которые я могу повторно использовать?
Я разрабатываю Win32, поскольку он существует ( > 15 лет). Его прямой и очень надежный, хотя иногда ему нужны еще несколько звонков, чем вы ожидали, и, конечно же, вам нужно отслеживать ручки и т.д. Но наше приложение (250 000 LOC) устанавливается менее чем за 1 минуту, и это очень редко имеет проблемы совместимости.
Я продолжил несколько обсуждений о SO о .NET против Win32 (т.
Win32 vs .Net). Но они не отвечают на эти вопросы.
Ответы
Ответ 1
Ответ довольно прост: более высокий уровень абстракции и развязки от "реальных" вещей за кулисами. Именно поэтому .NET может быть реализован в других операционных системах.
На самом деле все это возможно без .NET, но это практически невозможно. Краткий пример: WCF в .NET дает вам первый класс IPC и SOA Framework, которые каждый может использовать. Он встроен в функциональность. В win32 вы получаете такое же самокодирование, как и сторонние библиотеки или что-то еще. База пользователей небольшая, у вас нет такого большого сообщества, которое поддерживает вас с вашими проблемами, и это сложно реализовать..NET Framework предоставляет вам все это из коробки.
Для огромного количества приложений .NET ускорит время разработки и сделает разработку более дешевой.
Для специальных видов приложений верно обратное. НАПРИМЕР. (практически) невозможно создать приложения реального времени с .NET, потому что GC на Уровне 2 замораживает все ваши потоки.
Дополнительно:
.NET framework 4.5 включает дополненный сборщик мусора. Он позволяет многопоточную сборку мусора фона для сборщика мусора сервера (включен с элементом <gcServer> в app.config), который не задерживает потоки приложений.
К сожалению, сборщик мусора Mono не настолько продвинут, поэтому основной оператор все еще верен для Mono.
Ответ 2
ИМХО только тот, кто разрабатывал Win32 более 15 лет, мог бы назвать это простым и надежным. И если вы захотите написать все 250 000 строк самостоятельно, а не использовать компоненты, то обязательно, ваше приложение будет легко установить. Я не уверен, что компромисс обязательно стоит того.
Что .NET дает вам, это более быстрая разработка по разным причинам. Более высокие абстракции, отличные компоненты для загрузки, отсутствие проблем с указателем, меньше необходимости управлять собственной памятью или ручками. Если вы разрабатываете Win32 в течение 15 лет, возможно, вам это не понадобится. Вы когда-нибудь нанимали новых младших программистов? Я уверен, что они узнают .NET быстрее, чем Win32. Там так много, чтобы учиться в Win32, прежде чем вы можете даже сказать "Hello world".
Ответ 3
Я разработал игры на С++ около 8 лет, прежде чем переключиться на веб-разработку на ASP.NET/ASP.NET MVC. С моей точки зрения, это самые важные преимущества при использовании .NET вместо собственного кода на С++:
- Очень хорошие инструменты IDE. Resharper может сделать гораздо больше, чем VisualAssist
- Больше недействительных/нулевых ошибок указателя или проблем с утечкой памяти.
- Твердая среда выполнения с гораздо более удобным API, чем Win32
- Множество отличных библиотек .NET с открытым исходным кодом, больше, чем я мог найти для С++ (даже если нет С# Boost)
- Благодаря Mono перенос вашего программного обеспечения на другую платформу проще, чем с С++
Ответ 4
Простота использования. И легкая совместимость с остальной частью платформы .NET(части, не связанные с Win32).
В .NET нет ничего волшебного, это просто огромное количество предопределенных классов для простого выполнения простых задач. И многие из этих задач - это такие, как "создать окно" или другие функции Win32.
Что касается того, что Win32 является "простым и надежным", я так не думаю.
Вот замечательный пример: одна из самых фундаментальных функций, которые потребует программист: получение сообщения об ошибке, связанного с только что произошедшей ошибкой:
http://msdn.microsoft.com/en-us/library/ms679351%28VS.85%29.aspx
- 7 параметров
- Две таблицы для чтения для понимания параметров
- Замечания по безопасности, которые необходимо учитывать
- Специальные специальные функции (LocalFree), которые должны быть вызваны для освобождения системного буфера.
Просто для достижения этой простой функциональности? И это "прямолинейно"?
Win32 API - один из самых сложных, самых запутанных и сложных в использовании (правильно, по крайней мере) API. Единственное, что ему удается сделать последовательно - это сделать легкое, интуитивное использование неправильным и потребовать много усилий для достижения правильности.
Но, конечно, любой, кто провел десятилетие, работая с API, уже столкнулся с этими проблемами и привык к ним. Для вас это не проблема. И даже лучше, поскольку у вас уже есть приложение, вы можете также придерживаться его. Нет причин выкидывать его и начинать с .NET.
Но если вы начали проект с нуля сегодня, то
- Кривая обучения будет намного более дружественной в .NET(но опять же, если вы уже прошли кривую обучения, это менее важно)
- Объем ошибок будет уменьшен в .NET(гораздо сложнее назвать функции "неправильным" способом, и даже если вы это сделаете, может произойти меньшее количество плохих вещей)
- Было бы проще найти новых программистов, чтобы присоединиться к вашей команде.
- Большинство людей гораздо более продуктивны на языке С#, чем на C или С++. Одной из основных особенностей .NET-предложений является возможность использования языков .NET. По сравнению с этим, библиотека классов может считаться обледенением на торте.
Ответ 5
Резюме двух слов:
Сбор мусора.
Ответ 6
WinAPI предназначен для взаимодействия с Windows на самом низком уровне и охватывает все функции, которые ОС Windows предоставляет потребителям.
.Net - это фреймворк, среда выполнения и большая коллекция библиотек, которые служат для разных целей и абстрактны API Windows. Он в основном обеспечивает OO абстракции, которые скрывают API окон.
Если вы используете .Net, вы еще используете WinAPI прозрачно и можете использовать его напрямую, если вы выбрали PInvoking в собственный API.
Следует ли выбрать .Net поверх WinAPI, зависит от типа приложения, которое вы хотите создать. Если это сильно интегрированное приложение с оболочкой, тогда используйте WinAPI, если это не так, но вам нужно использовать мощные библиотеки XML, возможностей подключения (WCF), графического (WPF) или доступа к данным (ADO.Net, Linq) и нуждаются в повышении производительности .Net предлагает и торгует с некоторой гибкостью (вам нужно убедиться, что .Net работает на целевом компьютере, что больше не имеет большого значения) не является и проблемой, а затем выбрал .Net.
Ответ 7
Сама .NET фактически обертывает интерфейс Win32 API, поэтому в принципе вы ничего не можете сделать с .NET, с которым вы не могли бы справиться с Win32 API. Преимуществом .NET является простота разработки - что также означает более быстрые поставки и меньше ошибок. Возможности отладки также намного лучше в .NET.
Скорость установки и времени выполнения .NET не является большой проблемой. Вы можете написать crappy software на любом языке, так же, как вы можете написать хорошее программное обеспечение на любом языке. В .NET есть разные подсказки и трюки, чем в С++ (так что определенно кривая обучения там), но в итоге оба одинаково хороши.
Я даже слышал слухи о том, что хорошо написанная программа на С# может быть быстрее, чем эквивалентная программа на С++, потому что компилятор JIT может оптимизировать сборку для конкретного процессора, в то время как оптимизатор С++ может делать только общие оптимизации. Я не знаю, правда ли это.
Совместимость программного обеспечения .NET также похожа на С++. С одной стороны, для этого требуется установка .NET framework, но, с другой стороны, больше не адской DLL из-за сильных имен и GAC. И многие вещи уже находятся в стандартной установке, для которой вам обычно потребуются сторонние библиотеки на С++ (например, синтаксический анализ XML, подключение к базе данных, веб-сервисы SOAP, RPC и т.д.). Я думаю, что это уменьшает размер и меньше Исполняемые файлы .NET - это, безусловно, бонус.
Ответ 8
Трудно ответить на этот вопрос, не зная больше о характере вашего приложения. Если это типичное внутреннее деловое приложение с большим количеством доступа к db и генерации отчетов, я бы сказал, что .NET приносит много результатов в таблицу. Если это, например, игра или обработка изображений или вообще что-то, что вы продаете широкому кругу клиентов, я бы придерживался Win32.
Ответ 9
.NET дает вам возможность записывать хранимые процедуры Sql Server на реальных языках. Попробуйте сделать это в DLL Win32.
Ответ 10
Помимо пунктов, которые вы уже сделали.
- .NET менее зависим от платформы (под mono он будет работать в Windows, Linux, OS X, BSD и т.д.)
- Вы можете написать код .NET в VB, С#, С++ и т.д. и иметь модули, написанные на разных языках, все они работают счастливо вместе без особых проблем.
На самом деле, я думаю, вы обнаружите, что .NET обертывает много функций win32.
Ответ 11
Некоторые преимущества:
-
Поддержка нескольких языков. Теперь легко написать приложение в Delphi и использовать эту прикладную логику В коде, написанном в VB. Нет больше COM, не более экзотических методов вызова - просто "Добавить ссылку", и это просто работает. В основном, потому что, как всегда, возникают некоторые проблемы, но проблемы .NET практически отсутствуют по сравнению с COM.
-
Простота использования. В Win32 API каждый отдельный вызов должен иметь много кода инициализации. После инициализации вам обычно приходилось вызывать метод API с некоторыми флагами, чтобы знать, чего ожидать и как распределять буферы для этого вызова, а затем снова вызвать этот метод API, с другими параметрами, чтобы выполнить эту работу. В конце концов, был некоторый очищающий код. В .NET вы обычно просто вызываете какой-то метод, поскольку все беспорядочные вещи скрыты внутри.
-
.NET выше WinAPI. Итак, теперь Framework написан с использованием WinAPI, но через несколько лет (скажем, Windows 9?) Это будет .NET Framework, что будет отображаться ядром. Унаследованные приложения будут использовать какой-то унаследованный переводчик - WinAPI, написанный в .NET Framework.
Ответ 12
Когда я разрабатывал MS-DOS-приложения, я также задавался вопросом о чем-то подобном в разработке Windows. Окна были интересны, но я чувствовал, что DOS более практичен. То есть, пока я не начал писать приложения Windows и не заметил, что Windows API был весьма полезен. Окружающая среда RAD, которую я использовал для Windows (Delphi), очень упростила для меня разработку приятного графического интерфейса для моего приложения. С Borland Pascal это было немного сложнее, хотя Turbo Vision действительно обеспечивало очень полезную среду для DOS.
Когда .NET был представлен, около 8 лет назад, я просто считал, что это большая библиотека времени исполнения для приложений Windows, как и сама Windows, была классной графической библиотекой для MS-DOS. Это не Серебряная пуля или Золотой молот, чтобы поразить ваши проблемы в отношении решений. Это просто то, что облегчает процесс разработки.
Тем не менее, когда я сравниваю свои приложения Windows с MS-DOS, я все еще чувствую, что DOS еще более надежна. Но Windows делает многое, гораздо более возможным для меня, чтобы сделать с большой легкостью. То же самое происходит, когда вы сравниваете .NET с WIN32. Все становится легче развиваться.
Ответ 13
Я обнаружил, что редактор форм в Visual Studio Express 8 последовательно разбивает всю IDE, когда я кодирую С++ с .NET. Этого не происходит, когда я делаю С++ с простой Win32. Этого не происходит, когда я кодирую формы с .NET и С#, поэтому я был вынужден никогда не использовать .NET снова, кроме как с С#.
Ответ 14
Виртуальные машины, такие как использование .NET, очень хороши для кроссплатформенного кодирования. Если вы не совершаете неуправляемых вызовов вне функций .NET, то он может работать в любом месте .NET.
Как и X-Box 360. Или Windows CE/Mobile/Whatever.
Это будет хорошо для разработчиков Microsoft и Windows, потому что устройства с низким энергопотреблением будут более эффективными с процессором, подобным ARM. ARM не собирается запустить ваше приложение IA32 Windows, но оно запустит ваше приложение .NET после того, как MS получит через .NET для ARM WinCE.
Java тоже делает это, конечно, и ее лучше и более зрелым в кросс-платформенной поддержке, если это то, что вы собираетесь делать.