Alextp

|
Posted: Wed Mar 21, 2007 11:07 Post subject: |
|
|
Oleg F (sql.ru)
Guest
Quote: | Первые впечатления.
Я в начальной стадии изучения C# и .NET.
Только первый месяц мучаюсь.
Всё незнакомое сначала вызывает отторжение.
Но чувствую, что это необходимо. Поэтому мучаюсь.
Почему необходимо?
Потому что эту технологию проталкивает
Microsoft, и всё равно добьётся своего.
Если хотите, чтобы ваши программы нормально работали
в будущих версиях Windows (Vista и т.д.), нужно их писать под .NET.
У Win32 приложений (или как теперь говорят native кода) будет
с каждой версией Windows всё меньше шансов на корректную работу.
И только managed код (использующий типы CTS, для которых реализована
"сборка мусора") будет более долговечным. (не соот-ет действительности - A.T.)
*****
Если задаться вопросом, а что нового можно получить по сравнению
с Delphi?
Пока что вижу больше отрицательных моментов, чем положительных.
Из положительных моментов - технологии .NET Remouting и ASP.NET
Думаю, это те две основные ноги, на которых успешно продвигается
платформа .NET. Плюс поддержка Unicode. Для некоторых стран, в которых
одновременно используются более двух естественных языков,
это важно (но таких стран подавляющее меньшинство).
Хотя, с другой стороны, я вижу, что
SOAP протокол для взаимодействия программ является более устоявшимся
и по-настоящему кроссплатформенным (в отличие от .NET Remouting),
а скриптовые языки (в первую очередь PHP) постоянно совершенствуются
и в скором времени смогут приблизиться по возможностям к ASP.NET
Но языку PHP не хватает строгости, поэтому Java и C# для разработки
серьёзных корпоративных сайтов всё равно останутся более популярными.
*****
Что касается "сборки мусора" в .NET, то программист должен быть законченным
дебилом, чтобы у него утекло столько памяти, сколько жрут приложения под
.NET. "Cборка мусора" актуальна только для программ, работающих на сервере
приложений 24 часа в течение многих месяцев и обслуживающих сотни пользователей.
Только там небольшие утечки памяти могут слиться в одну большую реку и "сборка мусора"
действительно необходима. Для обычных desktop приложений она не нужна.
Там если утекло несколько мегабайт, не страшно. Пользователь вышел из программы
и ОС освободила память. Поэтому C# в первую очередь будет и уже применяется для разработки ASP.NET приложений и Web-сервисов, т.е. программного обеспечения
для серверов приложений.
****
Если сравнивать языки C# и Delphi образца 2006 года, то ничего революционно нового
в C# нет. Проштудировав книжку Шилдта по C# я обнаружил только
два новшества по сравнению с Delphi: пространства имён (в т.ч. вложенные)
и многоадресные делегаты. И то и другое может быть как благом, так и злом,
при неразумном использовании внося путаницу в программы.
Можно наплодить классов с одинаковыми названиями в разных пространствах имён,
а потом постоянно путаться, какой класс используется в данный момент.
*****
Если сравнивать компоненты VCL и .NET, то в .NET компонентах
свойств, методов, событий в среднем в 2-3 раза больше, чем в аналогичных
компонентах VCL. Видимо Microsoft задалась целью предусмотреть
практически всё. Опять же, это и достоинство, и недостаток.
На изучение любого .NET компонента и на понимание, что в нём действительно нужно,
а что шелуха, уходит в несколько раз больше времени, чем в Delphi.
Пока отделяешь "зёрна от плевел", течёт драгоценное рабочее время,
в течение которого на Delphi можно было бы много что написать.
И так с каждым компонентом. С другой стороны, на порядок реже
будет возникать необходимость искать сторонние компоненты, т.к. в .NET
компонентах практически всё уже есть.
Другое отличие - повсеместное использование "интерфейсов" в .NET Framework.
В Delphi интерфейсы тоже есть, но используются в VCL редко.
C ADO.NET пока серьёзно не разбирался, но пролистав пару книжек,
я понял, что это тоже жутко навороченная штука
по сравнению с ADO-компонентами в Delphi.
Даст выигрыш только в том случае, если нужно работать с данными
в режиме offline (присоединился, взял данные, отсоединился,
в оперативной памяти с данными поработал,
снова присоединился и отправил данные обратно
- т.е. без постоянного соединения с СУБД).
Это позволяет разгрузить СУБД, но актуально только для очень
больших информационных систем, т.к. несколько десятков пользователей могут держать постоянные соединения с базой в течение всего сеанса работы.
*****
Вот такие мои первые впечатления после месяца изучения C# в Visual Studio 2005
в фоновом режиме (т.е. по 1-2 часа в день в свободное от работы время). |
_________________ UniViewer - CudaText - LogViewer
|
|