Posted: Wed Jan 10, 2007 01:00Posted: Wed Jan 10, 2007 01:14Posted: Wed Jan 10, 2007 11:11
Posted: Tue Jan 30, 2007 20:37
Posted: Wed Mar 21, 2007 11:07| 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 часа в день в свободное от работы время). |
output generated using printer-friendly topic mod. All times are GMT + 4 Hours