Для чего нужен .Net Framework?

Автор Максус, 09 Січень 2008, 17:52:48

Попередня тема - Наступна тема
Друк
Вниз Сторінок1
Дії користувача

Максус

09 Січень 2008, 17:52:48 Останнє редагування: 01 Січень 2010, 13:50:01 від max.sim
Для чего нужен Net framework???

βεερ_βooρ

#1
09 Січень 2008, 17:54:34
Цитата: Максус від 09 Січень 2008, 17:52:48
Для чего нужен Net framework???
Для работы ряда программ. Подробнее тут.
Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.
All that's here is Fear! Suppression! Betrayal! Despair! Contempt! Regret! Sadness! Anguish! Madness! And Pain, right?

Edd.Dragon

#2
10 Січень 2008, 00:45:34
Цитата: Максус від 09 Січень 2008, 17:52:48
Для чего нужен Net framework???
.NET фреймворк - это огромный набор различных компонент, которые раньше приходилось писать самим (если простенькие) или же искать в сети - в результате панелька от Васи, таблички от Коли, а компоненты доступа к базам данных вообще (судя по документации, точнее ее отсутствию) от немого Герасима.

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

Т.е. по сути - это огромное количество различных библиотек готовых "кубиков" разного толка (от визуальных компонент до таймеров, драйверов БД и т.д.) для разработки ПО.

В общем, то, что Дельфи сделала, когда появилась (в конце 90-х) еще кажется под Windows 3.1, то наконец-то сейчас Микрософт сделал у себя (забрав кстати себе бывшего главного идеолога по Дельфи). Почему в Микрософте так долго тупили и считали, что этого делать не нужно - фиг его знает... Сейчас бы фреймворк был бы уже достаточно укоренившимся, отлаженым и т.д.


Платформой .NET называется потому, что .NET-приложение просто так не запустится, там не обычный исполняемый код. Для выполнения кода, скомпилированого под .NET, нужен специальный движок. При запуске приложения этот движок "докомпилирует" промежуточный код под платформу, на которой вы его запустили, только теперь получится обычный экзешник, которому движок и передаст управление. Именно поэтому .NET-проги могут долго грузиться первый раз.


ИТОГО:
.NET - платформа.
.NET Фреймворк - полный инструментарий разработчика под нее, без которого естественно ничего не пойдет, так же как и обычные проги без стандартных dll-ек из Windows\System32

βεερ_βooρ

#3
10 Січень 2008, 01:53:29
Цитата: edd_k від 10 Січень 2008, 00:45:34
компоненты доступа к базам данных вообще (судя по документации, точнее ее отсутствию) от немого Герасима.
Не юзайте BDE, SQL рулит. Простите не сдержался. Больная тема. :D

Цитата: edd_k від 10 Січень 2008, 00:45:34
А так глобальный продукт, коммерческого качества, с полной документацией, с единым подходом и т.д., в котором есть практически все, что нужно для большинства приложений. А во многих случаях, чтобы получить что-то под себя, надо не так уж и сильно доопределить уже имеющееся стандартное.
Вот только есть одно но...
Цитата: edd_k від 10 Січень 2008, 00:45:34
Т.е. по сути - это огромное количество различных библиотек готовых "кубиков" разного толка (от визуальных компонент до таймеров, драйверов БД и т.д.) для разработки ПО.
А конкретнее для разработчиков платформы .NET
Цитата: edd_k від 10 Січень 2008, 00:45:34
В общем, то, что Дельфи сделала, когда появилась (в конце 90-х) еще кажется под Windows 3.1,
В первом Дельфи даже бала опция как должны выгледить кнопочки: аля вин31 или аля вин95 ::)
Цитата: edd_k від 10 Січень 2008, 00:45:34
то наконец-то сейчас Микрософт сделал у себя
Ничего такого революционного в VCL не было - это был промежуточный слой между WinAPI и приложением. Основная фишка Дельфи была в быстрой и удобной разработке.
Цитата: edd_k від 10 Січень 2008, 00:45:34
(забрав кстати себе бывшего главного идеолога по Дельфи). Почему в Микрософте так долго тупили и считали, что этого делать не нужно - фиг его знает...
Откройте глаза на существование comctl32.dll и  comdlg32.dll.  Вот поэтому элементы интерфейса во многих приложениях одинаковы. Общий фреймворк(если несколько тысяч вызовов функций WinAPI можно так назвать) у них был давно...
Цитата: edd_k від 10 Січень 2008, 00:45:34
Сейчас бы фреймворк был бы уже достаточно укоренившимся, отлаженым и т.д.
Ха! Фреймворк который уже раза 3 терял обратную совместимость впечитления укоренившегося не производит.
Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.
All that's here is Fear! Suppression! Betrayal! Despair! Contempt! Regret! Sadness! Anguish! Madness! And Pain, right?

firefire

#4
13 Січень 2008, 17:32:31 Останнє редагування: 16 Січень 2008, 23:54:26 від POTTER
А не кто не знает как устранить вот эту проблему?

Edd.Dragon

#5
14 Січень 2008, 10:51:30
Цитата: beep_boop від 10 Січень 2008, 01:53:29
Откройте глаза на существование comctl32.dll и  comdlg32.dll.  Вот поэтому элементы интерфейса во многих приложениях одинаковы. Общий фреймворк(если несколько тысяч вызовов функций WinAPI можно так назвать) у них был давно...
Тут же суть не в том, что можно, а что нельзя назвать фреймворком - все это API. Суть в реализации - в одном случае API соответсвует современным нормам, а в другом - требует приведения к этим нормам, а так же доставляет неудобства и лишние потери времени.

Цитата: beep_boop від 10 Січень 2008, 01:53:29
Ха! Фреймворк который уже раза 3 терял обратную совместимость впечитления укоренившегося не производит.
А я разве сказал, что производит?

Цитата: beep_boop від 10 Січень 2008, 01:53:29
Ничего такого революционного в VCL не было - это был промежуточный слой между WinAPI и приложением. Основная фишка Дельфи была в быстрой и удобной разработке.
"Революционность" архитектуры VCL - это и есть причина и возможность для удобного и эффективного проектирования приложений. Используя не ООП-API каждый писал по сути свои VCL + RTL. Революционность в том и состояла, что наконец-то был сделан шаг к появлению стандартного ООП API, берущего на себя (пусть и частично) возню со старым API.

А вот у Микрософта до появления .NET был нормальный фреймворк - тот, на котором базируется интерфейс и функционал Офиса. Но был он внутренним.

βεερ_βooρ

#6
15 Січень 2008, 01:39:55
Цитата: edd_k від 14 Січень 2008, 10:51:30
Тут же суть не в том, что можно, а что нельзя назвать фреймворком - все это API. Суть в реализации - в одном случае API соответсвует современным нормам, а в другом - требует приведения к этим нормам, а так же доставляет неудобства и лишние потери времени.
Да, WinAPI успел прославиться своей уродливостью. А отпносительно реализации - см ниже.
Цитата: edd_k від 14 Січень 2008, 10:51:30
А я разве сказал, что производит?
То были мысли вслух.
Цитата: edd_k від 14 Січень 2008, 10:51:30
"Революционность" архитектуры VCL - это и есть причина и возможность для удобного и эффективного проектирования приложений.
Удобство проявлялось в первую очередь в виде Delphi IDE(или как вариант Билдер, в данном случие не важно) - без него VCL была вообщем то никому не нужной.
Цитата: edd_k від 14 Січень 2008, 10:51:30
Используя не ООП-API каждый писал по сути свои VCL + RTL.
Ввиду наличия мемеруаров и воспоминаний людей, который использовали WinAPI без намека на ООП позволю себе наглость не согласится.
Цитата: edd_k від 14 Січень 2008, 10:51:30
Революционность в том и состояла, что наконец-то был сделан шаг к появлению стандартного ООП API, берущего на себя (пусть и частично) возню со старым API.
А теперь относительно "революционности" и
Цитатастандартного ООП API, берущего на себя (пусть и частично) возню со старым API.
До появления VCL существовали OWL(Borland) и MFC.
Позже появились CLX, KOL&MCK
Все они предоставляют  "ООП API, берущего на себя (пусть и частично) возню со старым API"
Более того OWL и VCL имеют идейного предшествиника в виде TurboVision которая елала то же смое, но для ДОС.

Вообщем популярность VCL обусловлена никоим образом не указанными вами факторами.
Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.
All that's here is Fear! Suppression! Betrayal! Despair! Contempt! Regret! Sadness! Anguish! Madness! And Pain, right?

Edd.Dragon

#7
15 Січень 2008, 11:40:06
Цитата: beep_boop від 15 Січень 2008, 01:39:55
Удобство проявлялось в первую очередь в виде Delphi IDE(или как вариант Билдер, в данном случие не важно) - без него VCL была вообщем то никому не нужной.
Дык, я к тому, что не было бы Дельфи с удобной IDE без объектно-ориентированых API.

Цитата: beep_boop від 15 Січень 2008, 01:39:55
Ввиду наличия мемеруаров и воспоминаний людей, который использовали WinAPI без намека на ООП позволю себе наглость не согласится.
Мемуары наверное о том, как эти люди писали сложные клиент-серверные системы, например учетно-аналитические комплексы с распределенными структурами хранения данных и т.д?

Успешные бизнес-проекты с их масштабами и трудозатратами уже давно не мыслимы без ООП-подхода и кодировании и в менеджменте.

А если говорить о личном использовании, то и сейчас можно обходиться без фреймворка, директ-икса и т.д. Но как только будет достигнута некоторая черта сложности проекта и повторяемости подзадач в нем - у тебя тут же в голове начнет возникать мысль о необходимости некоторого подобия VCL или .NET Framework - и далее следует привычное изобретение велосипеда.

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

Естественно ни Борландовское, ни Микрософтовское творение не являются идеальными, но зато являются уже готовыми более-менее универсальными наборами с единой архитектурой, с единым менджемнтом. А в случае Микрософта - это вообще становится неотъемлимой частью винды.

И если бы Микрософт заворочался раньше - сейчас возможно их творение было бы гораздо юзабельнее и стандартнее чем есть. Что облегчило бы жизнь многим компаниям-разработчикам.

А "грамотный" фреймворк и удобный IDE - это вещи очень тесно взаимосвязанные. Унитаз за штуку баксов будет мало чем отличаться от старого треснувшего, если канализационный стояк под ним прогнил и засорился ;)


P.S.: На счет TurboVision согласен - революцию пожалуй именно он совершил!

βεερ_βooρ

#8
16 Січень 2008, 02:08:15
Цитата: edd_k від 15 Січень 2008, 11:40:06
Дык, я к тому, что не было бы Дельфи с удобной IDE без объектно-ориентированых API.
А я наоборот - не было бы IDE с графическим проектированием ИП - и о VCL мало кто помнил бы.
Цитата: edd_k від 15 Січень 2008, 11:40:06
Мемуары наверное о том, как эти люди писали сложные клиент-серверные системы, например учетно-аналитические комплексы с распределенными структурами хранения данных и т.д?
Не, трояны :)
Цитата: edd_k від 15 Січень 2008, 11:40:06
Успешные бизнес-проекты с их масштабами и трудозатратами уже давно не мыслимы без ООП-подхода и кодировании и в менеджменте.
Мы тут потихоньку скатываемся от темы. Начали с обсуждения фреймворков .NET и VCL. Закончили ООП.
А относительно "панацейности" ООП неплохо написано у Вирта и ESR:

ЦитатаМногие люди относятся к стилям и языкам программирования как к религиозным
конфессиям: если вы принадлежите к одной из них, то не можете принадлежать к другой. Но это
ложная аналогия, и она сознательно поддерживается по причинам коммерческого порядка.
Объектно-ориентированное программирование вышло из принципов и понятий традиционного
процедурного программирования. Скажу больше: в ООП не добавлено ни одного действительно
нового понятия; просто по сравнению с процедурным оно делает значительно более сильный
акцент на двух понятиях. Первое — это привязка процедуры к составной переменной, что и
послужило оправданием для введения терминов "объект" и "метод". Средством для такой
привязки является процедурная переменная (или поле записи — record field), доступная в языках
программирования с середины 70-х гг. Второе понятие — это конструирование нового типа
данных (названного "подкласс") путем расширения заданного типа ("суперкласс").
Стоит заметить, что вместе с ООП пришла совершенно новая терминология, имевшая целью
затемнить происхождение его корней. Таким образом, если раньше вы могли инициировать
активность процедуры путем ее вызова, то теперь должны посылать сообщение методу. Новый тип
строится не расширением заданного, а определением подкласса, который наследует от суперкласса.
Это вообще интересный феномен, когда многие люди узнают о таких важных (и древних!) понятиях,
как тип данных, инкапсуляция и (возможно) скрытие информации, лишь когда начинают изучать
объектно-ориентированное программирование. Что ж, одно это оправдывает излишний шум вокруг
ООП, даже если позднее эти неофиты ничего этого и не используют.

ESR обобщил опыт применения ООП в главах 4 и 14 "The Art of Unix Programming"
Unix and Object-Oriented Languages
http://www.catb.org/~esr/writings/taoup/html/ch14s04.html#cc_language
Цитата: edd_k від 15 Січень 2008, 11:40:06
А если говорить о личном использовании, то и сейчас можно обходиться без фреймворка, директ-икса и т.д. Но как только будет достигнута некоторая черта сложности проекта и повторяемости подзадач в нем - у тебя тут же в голове начнет возникать мысль о необходимости некоторого подобия VCL или .NET Framework - и далее следует привычное изобретение велосипеда.
Либо можно вспомнить мантру патриарха Макилроя:
"Делай хорошо одну вещь"
, но и о патриархе Томсоне нельзя забывать:
"Находясь в сомнении, используй грубую силу"
Цитата: edd_k від 15 Січень 2008, 11:40:06
Т.е. моя мысль - в сети давно есть тонны кода, из которых можно собрать свой фреймворк для проектов.
Более того, если я сочту это оправданным я так и делаю.
Цитата: edd_k від 15 Січень 2008, 11:40:06
Только при этом получается пестрая скатерть самобранка, которую долго собирать, долго тестировать, долго исправлять чужие глюки.
Смотря что брать и куда пихать ;)
Цитата: edd_k від 15 Січень 2008, 11:40:06
Естественно ни Борландовское, ни Микрософтовское творение не являются идеальными, но зато являются уже готовыми более-менее универсальными наборами с единой архитектурой, с единым менджемнтом. А в случае Микрософта - это вообще становится неотъемлимой частью винды.
...после чего я бегу покупать новый процессор, ибо просто пустое приложение с формой созданное с помощью VCL завесит кило на 300 минимум. Сейчас мб больше.
Цитата: edd_k від 15 Січень 2008, 11:40:06
А "грамотный" фреймворк и удобный IDE - это вещи очень тесно взаимосвязанные. Унитаз за штуку баксов будет мало чем отличаться от старого треснувшего, если канализационный стояк под ним прогнил и засорился ;)
Из вашего утверждения следует, что все тулкины для Винды одинаково галимы и мы должны подумывать о переходе на самосборные Линукс-уборные с биотуалетом.
Цитата: edd_k від 15 Січень 2008, 11:40:06
P.S.: На счет TurboVision согласен - революцию пожалуй именно он совершил!
Как таковой "революции" не сделал ни один из названных тулкитов.
Fear is the path to the dark side. Fear leads to anger. Anger leads to hate. Hate leads to suffering.
All that's here is Fear! Suppression! Betrayal! Despair! Contempt! Regret! Sadness! Anguish! Madness! And Pain, right?

Edd.Dragon

#9
16 Січень 2008, 11:08:46
Цитата: beep_boop від 16 Січень 2008, 02:08:15
...после чего я бегу покупать новый процессор, ибо просто пустое приложение с формой созданное с помощью VCL завесит кило на 300 минимум.
А процесор то ту при чем? Количество кода не совсем определяет его эффективность, хоть взаимосвязь и есть. Все зависит от того, что и как вы реализуете при помощи VCL и RTL.

Кстати, из визуальных недостатков VCL можно назвать "мультики" при прорисовке сложного интерфейса, связанные как раз с несовершенством модели графического интерфейса Винды, которая не очень подходит для обертки в объектно-ориентированый скелет.


Цитата: beep_boop від 16 Січень 2008, 02:08:15
Из вашего утверждения следует, что все тулкины для Винды одинаково галимы и мы должны подумывать о переходе на самосборные Линукс-уборные с биотуалетом.
Вопрос на засыпку: а зачем нам вообще какие-то языки программирования, если все в итоге сводится к машинным кодам? Почему мы ушли от асма?

--------------

Они не голимы. Но их использование их влоб при масштабах современных задач сильно снижает эффективность работы и надежность продукта.

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

Если вам нужно забить костыль в шпалу, то есть у вас кувалда или нет - а забить его нужно. В принципе можно воспользоваться и камнем, который у вас был до этого, но что делать со столь большими трудозатратами при столь низком качестве результата?

Или другая аналогия: объектно-ориентированное управление безсмыленно на фирме из пяти человек, но необходимо в крупной корпорации. При линейном управлении корпорация рухнет, т.к. ни один человек не в состоянии уследить за всем происходящим сразу. Это вроде очевидно. В процессе же перехода на корпоративную бизнес-модель каждый вырабатывал свои методы управления, позже опыт многих был собран в теорию и практику управления (стандартные фреймворки).

Так что, религия или нет - эта тема для теоретиков. А есть практика, которая диктует задачи и требует конкурентноспособных их решений (как с точки зрения качества, так и с точки зрения стоимости). Это сначала порождает спрос на инструменты соответсвующего уровня. А потом и появляются сами инструменты, такие как высокоэффективные IDE, стандартные фреймворки (тот же STL, который является по сути частью современного C++).

-----------

Отсюда и ответ на "вопрос на засыпку":
Когда программирование на асме превращается в хаос - происходит переход на новый мета-уровень. Результат этого перехода - линейное программирование на более "человеческих" языках, когда программист оперирует не перемещениями данных из памяти в регистры и сложением\вычитанием их, а уже более осмысленными абстракциями "вывести на дисплей", "посчтитать (a + b) / 2".

Когда и этого становится недосточно - происходит мета-переход к процедурным языкам, где
- каждая операция - множество  взаимодействующих машинных команд;
- каждая процедура - множество  взаимодействующих операций;
- результат - множество  взаимодействующих процедур.

Когда этого становится мало и мы начинаем мыслить объектами появляются предпосылки к ОО-языкам в виде реализации ОО-концепций через процедурные. О этом как раз и говорит Вирт, что изначально есть соответсвующее мышление, требующее изменения существующих инструментов под него. А в итоге появляется ООП-стандарт (теория + инструменты) и еще один слой:

- объект - множество  взаимодействующих процедур;
- результат - множество взаимодействующих объектов.

А так то, все это сложения\вычитания данных в процессоре и перемещение их туда-сюда. Но вручную это делать нынче даже в голову никому не прийдет.

[anti-offtop]
Вот для этого и нужны фреймворки как стандартные инструменты для эффективной реализации нынешних задач в их исконном объектно-ориентированом виде, рождающемся еще в мозге.

-----------

сорри, за офтоп
Друк
Нагору Сторінок1
Дії користувача