и предлагаю продолжить дискуссию здесь. Вероятно, обсуждением также заинтересуется Pavel_Lechenko.
Амбула.
Собственно, тезисы, котрые я предлагаю для оспаривания выглядят так:
1. .Net более всего подходит для построения коммуникационных инфраструктур.
2. Не всякая программа (в т.ч. и серверная) лучше всего реализуется средствами, ориентированными на построение коммуникаций.
3. (Вероятно, самый спорный тезис.) В программе, изначально не ориентированной на коммуникационные сервисы лучше всего предусмотреть просто интерфейс в инфраструктуру .Net, чтобы реализовывать коммуникационные задачи его средствами.
4. Если стоит задача обеспечения переносимости программы, не ориентированной на коммуникации, то .Net годится только для обеспечения коммуникационных сервисов на платформе Windows, а потому и не может быть выбран в качестве основного средства реализации.
Под словами "ориентация на ZZZZ" я подразумеваю, что ZZZZ есть основное назначение программы, без которого она не может существовать. Примеры:
— текстовый редактор ориентирован на редактирование текстов;
— SourceSafe ориентирован на хранение деревьев версий файлов;
— операционная система ориентирована на управление вычислительными процессами и ресурсами ЭВМ (блин, благородный древний слог );
Из этого, кстати, может следовать ещё пара интересных соображений.
5. Ориентированное на коммуникации программное обеспечение занимается исключительно обслуживанием коммуникаций и разрабатывается только для обслуживания коммуникаций.
6. Веб-сервис есть только способ осуществления коммуникации.
Признаюсь, что сформулированные тезисы далеко не бесспорны и для меня, а потому, собственно, жду pro & contra. Только одна просьба. Коллеги, давайте поменьше употреблять выражения типа "шаг вперёд", "светлое будущее" и т.п., чтобы не уподобляться автору статьи, упомянутой здесь
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Собственно, тезисы, котрые я предлагаю для оспаривания выглядят так:
ГВ>1. .Net более всего подходит для построения коммуникационных инфраструктур.
Возьмем ADO.NET и рассмотрим его не как технологию соединения программы с СУБД, а как тенхологию взяимодействия именно с БД. SOA стандартных конролов, способных взаимодействовать с Data Access провайдерами + Obj Spaces + XML поддержка
Возьмем ASP.NET (Web Forms). Что может хоть близко стоять с это технологией? На мой взгляд, вообще ничего.
Возьмем WinForms. Если рассматривать только часть отображения граффического интерфейса, то пока тут могут найтись конкуренты. Но если брать в учет дизайн поддержку, биндинг данных и, в будующем, XAML + Avalon, то конкуренты или быстро превратяться в NET, или вообще исчезнут.
ГВ>2. Не всякая программа (в т.ч. и серверная) лучше всего реализуется средствами, ориентированными на построение коммуникаций.
Не понятно. Ты имелл ввиду background программу, работаущую на сервере? Так зачем ей вообще коммутировать с кем то.
ГВ>3. (Вероятно, самый спорный тезис.) В программе, изначально не ориентированной на коммуникационные сервисы лучше всего предусмотреть просто интерфейс в инфраструктуру .Net, чтобы реализовывать коммуникационные задачи его средствами.
Выше было описано, что лучше максимально реализовать все средствами НЕТ. Конечно, можно нафигачить веб сервисы и общаться с ними на уровне сокетов. Но, веб сервисы, на мой взгляд, не очень удачное решение для внутрикорпоративного взаимодействия. Так же, что нам предоставляеться к веб сервисам в качестве бесплатного прибамбаса
1) WSE. Очень полезная вещь. Чтобы реализовать для клиента нужную ф-ть, потребудеться очень и очень много времени.
2) Indigo (для всех видов коммуникаций). Тут без комментариев.
ГВ>4. Если стоит задача обеспечения переносимости программы, не ориентированной на коммуникации, то .Net годится только для обеспечения коммуникационных сервисов на платформе Windows, а потому и не может быть выбран в качестве основного средства реализации.
Подожди. Фраза "не ориентированной на коммуникации" и "для обеспечения коммуникационных сервисов" себе противоречат. Конкретнее, плиз.
ГВ>5. Ориентированное на коммуникации программное обеспечение занимается исключительно обслуживанием коммуникаций и разрабатывается только для обслуживания коммуникаций.
Согласен.
ГВ>6. Веб-сервис есть только способ осуществления коммуникации.
Здравствуйте, mikа, Вы писали:
ГВ>>Собственно, тезисы, котрые я предлагаю для оспаривания выглядят так: ГВ>>1. .Net более всего подходит для построения коммуникационных инфраструктур.
M>Возьмем ADO.NET и рассмотрим его не как технологию соединения программы с СУБД, а как тенхологию взяимодействия именно с БД.
M> SOA стандартных конролов, способных взаимодействовать с Data Access провайдерами
Ну, ещё один способ непосредственной связи presentation-layer и data-layer. И что это кардинально меняет?
M> + Obj Spaces
M> + XML поддержка
А что это значит? ИМХО, это всего лишь один из форматов обмена данными, не более того. Да, он применяется везде, где только можно и нельзя, ну и что? ИМХО, LISP-представление значительно удобнее и проще.
M>Возьмем ASP.NET (Web Forms). Что может хоть близко стоять с это технологией? На мой взгляд, вообще ничего.
Докажи. Особенно правомерность обобщения "вообще". ИМХО, рядом с неё может стоять всё, что угодно, что обеспечит определённую платформонезависимость отображения.
M>Возьмем WinForms. Если рассматривать только часть отображения граффического интерфейса, то пока тут могут найтись конкуренты. Но если брать в учет дизайн поддержку, биндинг данных и, в будующем, XAML + Avalon, то конкуренты или быстро превратяться в NET, или вообще исчезнут.
Почему? Потому что все будут сметены мегавозможностями Avalon? Неубедительно. Ну год, ну два и появятся преемники, если это кому-нибудь будет нужно.
ГВ>>2. Не всякая программа (в т.ч. и серверная) лучше всего реализуется средствами, ориентированными на построение коммуникаций. M>Не понятно. Ты имелл ввиду background программу, работаущую на сервере? Так зачем ей вообще коммутировать с кем то.
Но доступ-то к ней по любому нужен. Другое дело, что основная задача, ради которой она запускается — совсем не коммуникационная, а какая-то ещё. Ну пусть тот же поиск данных, или сбор информации для OLAP.
ГВ>>3. (Вероятно, самый спорный тезис.) В программе, изначально не ориентированной на коммуникационные сервисы лучше всего предусмотреть просто интерфейс в инфраструктуру .Net, чтобы реализовывать коммуникационные задачи его средствами. M>Выше было описано, что лучше максимально реализовать все средствами НЕТ. Конечно, можно нафигачить веб сервисы и общаться с ними на уровне сокетов.
Причём тут сокеты? И зачем делать общаться с веб-сервисами на уровне сокетов?
M>Но, веб сервисы, на мой взгляд, не очень удачное решение для внутрикорпоративного взаимодействия. Так же, что нам предоставляеться к веб сервисам в качестве бесплатного прибамбаса M>1) WSE. Очень полезная вещь. Чтобы реализовать для клиента нужную ф-ть, потребудеться очень и очень много времени.
Э... а эту аббревиатуру можно раскрыть?
M>2) Indigo (для всех видов коммуникаций). Тут без комментариев.
Угу, именно, что для всех видов коммуникаций. Только почему это он в виде бесплатного прибамбаса к веб-сервисам? ИМХО, всё как раз наоброт обстоит.
ГВ>>4. Если стоит задача обеспечения переносимости программы, не ориентированной на коммуникации, то .Net годится только для обеспечения коммуникационных сервисов на платформе Windows, а потому и не может быть выбран в качестве основного средства реализации. M>Подожди. Фраза "не ориентированной на коммуникации" и "для обеспечения коммуникационных сервисов" себе противоречат. Конкретнее, плиз.
Нет, противоречия здесь нет. Программа сама по себе может быть и не ориентированной на коммуникации, но в то же время, у неё могут быть отдельные коммуникационные возможности. Тот же самый поиск в отдельных случаях может работать на локальном десктопе, а может — и из-под веб-сервиса. Веб-сервис можно добавить, можно убрать, возможности программы поиска от этого не изменятся.
ГВ>>5. Ориентированное на коммуникации программное обеспечение занимается исключительно обслуживанием коммуникаций и разрабатывается только для обслуживания коммуникаций. M>Согласен.
ГВ>>6. Веб-сервис есть только способ осуществления коммуникации. M>Его для его и создавали.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Там, одного комментария не хватает:
M> + Obj Spaces
А они-то что кардинально меняют?
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
M>Возьмем ADO.NET и рассмотрим его не как технологию соединения программы с СУБД, а как тенхологию взяимодействия именно с БД. SOA стандартных конролов, способных взаимодействовать с Data Access провайдерами + Obj Spaces + XML поддержка
M>Возьмем ASP.NET (Web Forms). Что может хоть близко стоять с это технологией? На мой взгляд, вообще ничего.
А причем тут .Net вообще? в приведенных примерах .Net это не технология а средство, инструмент.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, Геннадий Васильев, Вы писали:
M>> SOA стандартных конролов, способных взаимодействовать с Data Access провайдерами ГВ>Ну, ещё один способ непосредственной связи presentation-layer и data-layer. И что это кардинально меняет?
А кто сказал что это data-layer? Вот допустим я написал веб сервис. Он мне возвращает список товаров. Потом создал DataGrid и прибиндил к нему этот сервис. Я разве что то соединил? Нет. Я решил проблему без лишнего гемморного кода. При этом, веб сервис это не уровень доступа данных Это Business уровень, его фасад.
M>> + Obj Spaces ГВ>А они-то что кардинально меняют?
Чесно говоря, я и сам пока не понял зачем их вообще создавали, если все кричали что Юкон, Юкон. Но в любом случае, щас проведу маркетинговую беседу
Зайди на форум .NET и увидишь, что самый оцененный топик сейчас — это статья ИТ про RSDN.Framework.Data. Неспроста. Маппинг данных народу хочеться, а не возюкаться с SqlXXX классами. Чтоб быстро и эффективно (по времени разработки, разумеется).
M>> + XML поддержка ГВ>А что это значит? ИМХО, это всего лишь один из форматов обмена данными, не более того. Да, он применяется везде, где только можно и нельзя, ну и что? ИМХО, LISP-представление значительно удобнее и проще.
Вообщем, еще одна тема, XML и LISP.
Xml удобен для общения. Не нужно ничего нового изучать. Вот он протокол и все им пользуйтесь. А что ЛИСП. Я его не знаю. Следовательно, его не знаю и мои сервисы. Какой же он тогда удобный?
M>>Возьмем ASP.NET (Web Forms). Что может хоть близко стоять с это технологией? На мой взгляд, вообще ничего. ГВ>Докажи. Особенно правомерность обобщения "вообще". ИМХО, рядом с неё может стоять всё, что угодно, что обеспечит определённую платформонезависимость отображения.
ASP.NET удобен не своей платформонезависимостью (зачем браузеру знать, какая операционка хостит сервер?). Он предоставляет богатый выбор элементов управления, удобность в доступе данных, отладку, визуальную разработку (ну тут скорее всего спасибо студии), легкость программирования "низов" (аналоги ISAPI фильтров и расширение, которые можно создать в считанные минуты и так же развернуть). Плюс куча разных стартовых движков.
M>>Возьмем WinForms. Если рассматривать только часть отображения граффического интерфейса, то пока тут могут найтись конкуренты. Но если брать в учет дизайн поддержку, биндинг данных и, в будующем, XAML + Avalon, то конкуренты или быстро превратяться в NET, или вообще исчезнут.
ГВ>Почему? Потому что все будут сметены мегавозможностями Avalon? Неубедительно. Ну год, ну два и появятся преемники, если это кому-нибудь будет нужно.
Появяться. Сначала Avalon 2. Потом Avalon 3. На самом деле сама технология мне не интересна. Ну там скорость увеличиться, красивее. Мне это все лично по боку. Я первую проблему могу решить покупкой нового компа, вторую — я вообще не люблю попугаев. Но вот интересна сама идея вокруг XAML. Ну что могут предложить "конкуренты". Често говоря, я вижу только одного конкурента языку C# (ниче, если я конкретно). C# Builder
ГВ>>>2. Не всякая программа (в т.ч. и серверная) лучше всего реализуется средствами, ориентированными на построение коммуникаций. M>>Не понятно. Ты имелл ввиду background программу, работаущую на сервере? Так зачем ей вообще коммутировать с кем то.
ГВ>Но доступ-то к ней по любому нужен. Другое дело, что основная задача, ради которой она запускается — совсем не коммуникационная, а какая-то ещё. Ну пусть тот же поиск данных, или сбор информации для OLAP.
NT Services. Как можно подключиться к контроллеру этих сервисов с другой машины. Через оснастку. Какие тут еще коммуникации. Да, там есть RPC. Но все так хитро скрыто, что не нужно разработчику об этом знать.
Кстати, NT сервисы так же легко и приятно разрабатывать на Нете. Говорю это как программист, писавщий их сначала на голом АПИ, затем на аттрибутном ATL. Позднее на НЕТ.
ГВ>>>3. (Вероятно, самый спорный тезис.) В программе, изначально не ориентированной на коммуникационные сервисы лучше всего предусмотреть просто интерфейс в инфраструктуру .Net, чтобы реализовывать коммуникационные задачи его средствами. M>>Выше было описано, что лучше максимально реализовать все средствами НЕТ. Конечно, можно нафигачить веб сервисы и общаться с ними на уровне сокетов.
ГВ>Причём тут сокеты? И зачем делать общаться с веб-сервисами на уровне сокетов?
А как ты хочешь с ними общаться? В Нете уже есть классы, реализующие определенный слой абстракции. В Яве тоже есть (но я ее рассматриваю как Нет. Тот же мифический тяжеловестный рантайм, те же тормоза, та же легкость в разработке). А в других языках разве что то наблюдается? Да, и тем более, реализуй это, тут же потребуються дополнительные возможности, которые сейчас успешно берет на себя WSE. И эту библиотеку тоже реализовывать!?
M>>Но, веб сервисы, на мой взгляд, не очень удачное решение для внутрикорпоративного взаимодействия. Так же, что нам предоставляеться к веб сервисам в качестве бесплатного прибамбаса M>>1) WSE. Очень полезная вещь. Чтобы реализовать для клиента нужную ф-ть, потребудеться очень и очень много времени. ГВ>Э... а эту аббревиатуру можно раскрыть?
Web Services Enhancements. Предоставлял (я его помню по первой версии) шифромание траффика, аутентификацию, транзакционность, легкость в работе с DIME.
M>>2) Indigo (для всех видов коммуникаций). Тут без комментариев.
ГВ>Угу, именно, что для всех видов коммуникаций. Только почему это он в виде бесплатного прибамбаса к веб-сервисам? ИМХО, всё как раз наоброт обстоит.
Не. Только WSE бесплтаный прибамбас Ладно, а конкретно есть что нить по этому пункту. Ее на клиенте тоже самому придеться реализовывать?
ГВ>>>4. Если стоит задача обеспечения переносимости программы, не ориентированной на коммуникации, то .Net годится только для обеспечения коммуникационных сервисов на платформе Windows, а потому и не может быть выбран в качестве основного средства реализации. M>>Подожди. Фраза "не ориентированной на коммуникации" и "для обеспечения коммуникационных сервисов" себе противоречат. Конкретнее, плиз.
ГВ>Нет, противоречия здесь нет. Программа сама по себе может быть и не ориентированной на коммуникации, но в то же время, у неё могут быть отдельные коммуникационные возможности. Тот же самый поиск в отдельных случаях может работать на локальном десктопе, а может — и из-под веб-сервиса. Веб-сервис можно добавить, можно убрать, возможности программы поиска от этого не изменятся.
Здравствуйте, mikа, Вы писали:
ГВ>>Программа сама по себе может быть и не ориентированной на коммуникации, но в то же время, у неё могут быть отдельные коммуникационные возможности. Тот же самый поиск в отдельных случаях может работать на локальном десктопе, а может — и из-под веб-сервиса. Веб-сервис можно добавить, можно убрать, возможности программы поиска от этого не изменятся.
Знаешь, после этого высказывания ты меня навел на одну мысль. Может я покажусь слишком дерзким, тогда заранее прости.
А ты вообще представляешь что такое .NET? Тебя что то все на коммуникацию тянет. Может ассоциации с .NETWORK
Я вот лично не представляю, зачем веб сервису нужно обращаться к локальной программе, написанной, допустим на C++, и возвращать спикой файлов. Почему все это нельзя сразу написать на НЕТ? Возможности у него самые большие. Зачем тогда мучиться и писать что-то на другом языке?
Здравствуйте, mikа, Вы писали:
M>Я вот лично не представляю, зачем веб сервису нужно обращаться к локальной программе, написанной, допустим на C++, и возвращать спикой файлов. Почему все это нельзя сразу написать на НЕТ? Возможности у него самые большие. Зачем тогда мучиться и писать что-то на другом языке?
А как же унаследованный код? А сложные вычисления? Вы вспоминали DataGrid -- но неужели вы хотите и кластерные вычисления для них писать на Шарпе? Вдобавок -- почему мучаться? Сложную вычислительную логику целесообразнее реализовать на С++, а просто сложную -- на Хаскеле. Правда в отношении последнего .Net даёт надежду на простую и безболезненную интеграцию с остальным кодом. За это --
M>Я вот лично не представляю, зачем веб сервису нужно обращаться к локальной программе, написанной, допустим на C++, и
А веб сервис эжто не локальная программа, выполняющаяся на сервере? И какая разница на чем она написана?
Мы не о языковом срекдстве говорим а о технологии (или я один ? )
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
ГВ>1. .Net более всего подходит для построения коммуникационных инфраструктур.
Есть два толкования.
".NET больше подходит для коммуникаций, чем другие среды (напр. J2EE, Corba)"
".NET больше подходит для коммуникаций, чем для других вещей (напр. рисования или мат. функций)"
Похоже, ты имел ввиду второе.
Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. Преимущества вытекают отсюда. Одно из основных — безопасность. Перефразируя твою фразу,
.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры.
Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. Грубо говоря, C со товарищи.
Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры.
Если же говорить о коммуникациях, то тут преимущества, вроде бы, не такие уж принципиальные. Метаданные — да, это то, что упрощает поддержку коммуникаций. Но метаданные есть и в "старых" архитектурах. Например в COM TLB достаточно метаданных, чтобы обеспечить приличные коммуникационные возможности. Ведь известно, что в Win2003 обычные COM-компоненты могут публиковаться как те же веб-сервисы.
Если же сравнивать с Java, то тут я вообще не понимаю, какие особые преимущества есть у .NET. Конечно, всё подчищено, время-то идёт. Assembly/Type identity однозначно определено, custom атрибуты — тоже очень полезное приобретение. Сам IL вроде для JIT-компиляции больше заточен. Но это не столь принципиальные преимущества (ну, разве что атрибуты). То есть коммуникационные возможности Java должны быть, потенциально, сравнимы с .NET.
Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl.
Здравствуйте, mikа, Вы писали:
M>Здравствуйте, Геннадий Васильев, Вы писали:
M>>> SOA стандартных конролов, способных взаимодействовать с Data Access провайдерами ГВ>>Ну, ещё один способ непосредственной связи presentation-layer и data-layer. И что это кардинально меняет?
M>А кто сказал что это data-layer? Вот допустим я написал веб сервис. Он мне возвращает список товаров. Потом создал DataGrid и прибиндил к нему этот сервис. Я разве что то соединил? Нет. Я решил проблему без лишнего гемморного кода. При этом, веб сервис это не уровень доступа данных Это Business уровень, его фасад.
Хорошо, согласен, таким образом ты прикрутил исходящий от сервера поток данных к презентационному слою. Т.е., выполнил работу по коммутированию потока данных. DataGrid написан средствами .Net. Значит, коммуникации + представление. Почти убеждаешь...
Но с другой стороны — собственный продукт Microsoft и окошки бы не умел рисовать? Я DataGrid глубоко не ковырял, но что-то мне подсказывает, что он, всё-таки, как и любой custom control обеспечивается службами самой Windows: очередями сообщений, WM_PAINT-ами и прочим. И ещё: если у тебя вместо плоской таблицы появится древовидная структура, то и вместо DataGrid придётся что-то другое вешать, не правда ли?
M>>> + Obj Spaces ГВ>>А они-то что кардинально меняют?
M>Чесно говоря, я и сам пока не понял зачем их вообще создавали, если все кричали что Юкон, Юкон. Но в любом случае, щас проведу маркетинговую беседу
Ну давай, проводи.
M>Зайди на форум .NET и увидишь, что самый оцененный топик сейчас — это статья ИТ про RSDN.Framework.Data. Неспроста. Маппинг данных народу хочеться, а не возюкаться с SqlXXX классами. Чтоб быстро и эффективно (по времени разработки, разумеется).
Ну, маппинг — тема отдельная и достаточно большая. К дотнету, ИМХО, она относится очень даже косвенно, хотя, если хочешь, то можно поковырять и её. Да, на дотнете CRUD стало делать легко. Но объектно-реляционный маппинг одним только CRUD не ограничивается, это простейшая штуковина, которая при наличии устаканенного подхода к описанию и чтению структуры класса лепится вполпинка почти на любом языке.
M>>> + XML поддержка ГВ>>А что это значит? ИМХО, это всего лишь один из форматов обмена данными, не более того. Да, он применяется везде, где только можно и нельзя, ну и что? ИМХО, LISP-представление значительно удобнее и проще. M>Вообщем, еще одна тема, XML и LISP. M>Xml удобен для общения. Не нужно ничего нового изучать. Вот он протокол и все им пользуйтесь. А что ЛИСП. Я его не знаю. Следовательно, его не знаю и мои сервисы. Какой же он тогда удобный?
Для веб-сервисов, может быть и неудобный. Пока. А так, вобщем-то, покомпактнее XML будет. Да и нет необходимости XSLT изобретать: все трансформации можно описать на том же LISP. Единственное серьёзное отличие: человеку его потруднее читать, чем XML и не так уж он и годится для разметки текста. Ну впрочем, ладно, это к теме не относится.
M>>>Возьмем ASP.NET (Web Forms). Что может хоть близко стоять с это технологией? На мой взгляд, вообще ничего. ГВ>>Докажи. Особенно правомерность обобщения "вообще". ИМХО, рядом с неё может стоять всё, что угодно, что обеспечит определённую платформонезависимость отображения.
M>ASP.NET удобен не своей платформонезависимостью (зачем браузеру знать, какая операционка хостит сервер?). Он предоставляет богатый выбор элементов управления, удобность в доступе данных, отладку, визуальную разработку (ну тут скорее всего спасибо студии), легкость программирования "низов" (аналоги ISAPI фильтров и расширение, которые можно создать в считанные минуты и так же развернуть). Плюс куча разных стартовых движков.
Да, но назначение ASP — работа в коммуникационной среде. Каких бы прибамбасов там ни было, "среда" для ASP всё равно — коммуникационная. Ну, плюс ещё презентативная логика в определённом смысле.
M>>>Возьмем WinForms. Если рассматривать только часть отображения граффического интерфейса, то пока тут могут найтись конкуренты. Но если брать в учет дизайн поддержку, биндинг данных и, в будующем, XAML + Avalon, то конкуренты или быстро превратяться в NET, или вообще исчезнут. ГВ>>Почему? Потому что все будут сметены мегавозможностями Avalon? Неубедительно. Ну год, ну два и появятся преемники, если это кому-нибудь будет нужно. M>Появяться. Сначала Avalon 2. Потом Avalon 3. На самом деле сама технология мне не интересна. Ну там скорость увеличиться, красивее. Мне это все лично по боку. Я первую проблему могу решить покупкой нового компа, вторую — я вообще не люблю попугаев. Но вот интересна сама идея вокруг XAML. Ну что могут предложить "конкуренты". Често говоря, я вижу только одного конкурента языку C# (ниче, если я конкретно). C# Builder
Хорошо, тогда не будем гадать на кофейной гуще. Поживём-посмотрим.
ГВ>>>>2. Не всякая программа (в т.ч. и серверная) лучше всего реализуется средствами, ориентированными на построение коммуникаций. M>>>Не понятно. Ты имелл ввиду background программу, работаущую на сервере? Так зачем ей вообще коммутировать с кем то. ГВ>>Но доступ-то к ней по любому нужен. Другое дело, что основная задача, ради которой она запускается — совсем не коммуникационная, а какая-то ещё. Ну пусть тот же поиск данных, или сбор информации для OLAP.
M>NT Services. Как можно подключиться к контроллеру этих сервисов с другой машины. Через оснастку. Какие тут еще коммуникации. Да, там есть RPC. Но все так хитро скрыто, что не нужно разработчику об этом знать.
Да, нет. Мир одной только NT не ограничивается.
M>Кстати, NT сервисы так же легко и приятно разрабатывать на Нете. Говорю это как программист, писавщий их сначала на голом АПИ, затем на аттрибутном ATL. Позднее на НЕТ.
Да знаю, знаю.
ГВ>>>>3. (Вероятно, самый спорный тезис.) В программе, изначально не ориентированной на коммуникационные сервисы лучше всего предусмотреть просто интерфейс в инфраструктуру .Net, чтобы реализовывать коммуникационные задачи его средствами. M>>>Выше было описано, что лучше максимально реализовать все средствами НЕТ. Конечно, можно нафигачить веб сервисы и общаться с ними на уровне сокетов.
ГВ>>Причём тут сокеты? И зачем делать общаться с веб-сервисами на уровне сокетов?
M>А как ты хочешь с ними общаться?
Ну, я вообще-то думаю, что с веб-сервисами лучше всего через SOAP общаться, а сокеты нужны там, где производительность SOAP не устраивает.
M>В Нете уже есть классы, реализующие определенный слой абстракции. В Яве тоже есть (но я ее рассматриваю как Нет. Тот же мифический тяжеловестный рантайм, те же тормоза, та же легкость в разработке). А в других языках разве что то наблюдается? Да, и тем более, реализуй это, тут же потребуються дополнительные возможности, которые сейчас успешно берет на себя WSE. И эту библиотеку тоже реализовывать!?
Может быть и так, может быть и нет. Во всяком случае, это никак не противоречит тому, что .Net ориентирована в первую очередь на коммуникации и их обслуживание.
M>>>Но, веб сервисы, на мой взгляд, не очень удачное решение для внутрикорпоративного взаимодействия. Так же, что нам предоставляеться к веб сервисам в качестве бесплатного прибамбаса M>>>1) WSE. Очень полезная вещь. Чтобы реализовать для клиента нужную ф-ть, потребудеться очень и очень много времени. ГВ>>Э... а эту аббревиатуру можно раскрыть?
M>Web Services Enhancements. Предоставлял (я его помню по первой версии) шифромание траффика, аутентификацию, транзакционность, легкость в работе с DIME.
Коммуникации.
шифромание траффика — коммуникации
аутентификацию — коммуникации, поскольку решение об авторизации всё равно принимается той системой, что обеспечивает функционирование веб-сервиса
транзакционность — коммуникационная поддержка транзакций, поскольку транзакции реально обеспечиваются базами данных и прочими провайдерами (в некоторых случаях, они могут быть написаны на "чистом" .Net).
DIME — лучше всего на этот счёт скажет MSDN:
DIME and WS-Attachments form a simple and efficient solution for packaging attachments with SOAP messages.
То есть — поддержка коммуникационного протокола.
Вывод: WSE, как и сами веб-сервисы — только коммуникационная приблуда. Хорошая, но коммуникационная.
M>>>2) Indigo (для всех видов коммуникаций). Тут без комментариев. ГВ>>Угу, именно, что для всех видов коммуникаций. Только почему это он в виде бесплатного прибамбаса к веб-сервисам? ИМХО, всё как раз наоброт обстоит. M>Не. Только WSE бесплтаный прибамбас Ладно, а конкретно есть что нить по этому пункту.
Не в платности/бесплатности дело. Всё равно — коммуникационный.
M>Ее на клиенте тоже самому придеться реализовывать?
Только объясни, плз., кого, "её" на клиенте реализоывать?
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mikа, Вы писали:
ГВ>>>Программа сама по себе может быть и не ориентированной на коммуникации, но в то же время, у неё могут быть отдельные коммуникационные возможности. Тот же самый поиск в отдельных случаях может работать на локальном десктопе, а может — и из-под веб-сервиса. Веб-сервис можно добавить, можно убрать, возможности программы поиска от этого не изменятся.
M>Знаешь, после этого высказывания ты меня навел на одну мысль. Может я покажусь слишком дерзким, тогда заранее прости.
M>А ты вообще представляешь что такое .NET? Тебя что то все на коммуникацию тянет. Может ассоциации с .NETWORK
Да, представляю. Но ассоциации с коммуникациями у меня не из-за .Network, а именно из-за внутренностей самого .Net.
M>Я вот лично не представляю, зачем веб сервису нужно обращаться к локальной программе, написанной, допустим на C++, и возвращать спикой файлов.
Странно... зачем? Затем, чтобы получить от неё какую-то информацию. Или заставить её что-то сделать.
M>Почему все это нельзя сразу написать на НЕТ? Возможности у него самые большие. Зачем тогда мучиться и писать что-то на другом языке?
Ну, Mika... "Возможности у него самые большие." Самые большие по сравнению с чем? Возможности-то большие, вопрос в том, для чего они лучше всего годятся. На VB можно, в принципе, любую программу написать, но не факт, что она позволит удовлетоврить предъявляемым к ней требованиям. Мне приходилось с АБС на VB сталкиваться — так этот монстр на четырёхпроцессорном сервере двух пользователей с трудом обслуживал.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, dad, Вы писали:
dad>Мы не о языковом срекдстве говорим а о технологии (или я один ? )
Не один
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, mihailik, Вы писали:
ГВ>>1. .Net более всего подходит для построения коммуникационных инфраструктур. M>Есть два толкования. M>".NET больше подходит для коммуникаций, чем другие среды (напр. J2EE, Corba)" M>".NET больше подходит для коммуникаций, чем для других вещей (напр. рисования или мат. функций)" M>Похоже, ты имел ввиду второе.
Да, именно.
M>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. Преимущества вытекают отсюда. Одно из основных — безопасность. Перефразируя твою фразу, M>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. Грубо говоря, C со товарищи.
Не совсем так. С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". Но с другой стороны, .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость, а заодно и переносимость. Так сказать — fool protection у неё получше. Просто в Java доступ к небезопасным возможностям сложнее, чем в .Net => шаловливые ручонки будут менее шаловливыми. Хм... Вот тебе, бабушка и Юрьев день.
Собственно, безопасность приложения для других обычно обеспечивается механизмами разделения адресных пространств средствами ОС. Более надёжного механизма, ИМХО, ещё не придумали.
M>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры.
Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй...
M>Если же говорить о коммуникациях, то тут преимущества, вроде бы, не такие уж принципиальные. Метаданные — да, это то, что упрощает поддержку коммуникаций. Но метаданные есть и в "старых" архитектурах. Например в COM TLB достаточно метаданных, чтобы обеспечить приличные коммуникационные возможности. Ведь известно, что в Win2003 обычные COM-компоненты могут публиковаться как те же веб-сервисы.
ИМХО, здесь основное преимущество в том, что ты можешь относительно просто отобразить одну и ту же структуру вызовов на разные способы их оформления. Ну, например: COM -> SOAP, COM -> custom, SOAP -> что-то ещё. Что, кстати и подтверждается возможностями Win2003.
M>Если же сравнивать с Java, то тут я вообще не понимаю, какие особые преимущества есть у .NET. Конечно, всё подчищено, время-то идёт. Assembly/Type identity однозначно определено, custom атрибуты — тоже очень полезное приобретение. Сам IL вроде для JIT-компиляции больше заточен. Но это не столь принципиальные преимущества (ну, разве что атрибуты). То есть коммуникационные возможности Java должны быть, потенциально, сравнимы с .NET.
Так они и так сравнимы именно за счёт библиотек. Просто скорость адаптации коммуникационных приложений к "новым веяниям" на Java, ИМХО, будет несколько ниже, чем на .Net. Но опять таки, — не так уж это и принципиально.
M>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl.
Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
dad>>Мы не о языковом срекдстве говорим а о технологии (или я один ? ) ГВ>Не один
Просто топик похож на обсуждение .Net, а в тексте было заявлено о яве.
Помоему даже беглый взгляд показывает, что ява превосходит .net во всех остношениях. Сказывается академический , а не коммерческий подход.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Здравствуйте, dad, Вы писали:
dad>>>Мы не о языковом срекдстве говорим а о технологии (или я один ? ) ГВ>>Не один
dad>Просто топик похож на обсуждение .Net, а в тексте было заявлено о яве. dad>Помоему даже беглый взгляд показывает, что ява превосходит .net во всех остношениях.
Ты только очень громко этого не говори.
dad>Сказывается академический , а не коммерческий подход.
Да здесь ещё много тем подняться может. А о Java, ИМХО, не упомянуть просто не получится. Куда ж мы без неё в контексте коммуникаций.
... << RSDN@Home 1.1.2 beta 2 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
M>>Какие тут могут быть возражения? Сущность .NET — управляемый код, снабжённый полными метаданными. Преимущества вытекают отсюда. Одно из основных — безопасность. Перефразируя твою фразу, M>>.NET больше подходит для построения безопасных приложений, чем "старые" архитектуры. M>>Под "старыми" архитектурами я понимаю компилируемые в ассемблерный код приложения. Грубо говоря, C со товарищи.
ГВ>Не совсем так. С одной стороны — да, система, принципиально контролирующая весь доступ к памяти обеспечивает несколько большую безопасность, чем "C со-товарищи". Но с другой стороны, .Net за счёт unmanaged-ов даёт в руки разработчика всё необходимое для любых издевательств над безопасностью. И получается, что Java с его JNI обеспечивает бОльшую защищённость
В .NET это регулируется политиками. Чтобы использовать unsafe-код или Platform Invoke, нужно иметь соответствующие права. То есть, опасность может исходить только от опрометчивых настроек и разрешений.
Во всяком случае, я бы не назвал неудобство работы с JNI преимуществом Явы. Хотя это, конечно, и усиливает барьер для издевательств над безопасностью.
M>>Кроме того, управляемость и метаданные дают больший потенциал для масштабирования. Если программа работает предсказуемо, его проще разносить на разные сервера, в разные домены и т.п. В том числе, и на разные процессорные архитектуры.
ГВ>Теоретически — да, но практически мне ещё не доводилось встречаться с .Net ни на AS/400 ни на Sparc. Зато Java там хоть отбавляй...
Да, там, наверное, дотнет и не выстрелит. Зато на IA64 скоро выстрелит.
M>>Ещё есть преимущества библиотек. Но это уже заслуга не рантайма, а исключительно библиотек. WinForms — хорошо. GDI+ — удобно. ASP.NET — просто качественный прорыв. Собственно, никто не мешает написать подобные библиотеки на Java, С++ или Perl.
ГВ>Согласен. На C++ — не мешает, на Java будет несколько сложнее переносимость фичечек того же GDI+ обеспечить.
Да уж, GDI+ переносимостью обделён. Зато, наверное, какой-нибудь JSP.NET запустят (или, лучше, JSP.ONE, но с тем де смыслом).
R>Вы вспоминали DataGrid -- но неужели вы хотите и кластерные вычисления для них писать на Шарпе?
Смотря какие вычисления. Бизнес-логику, к примеру самое оно — на шарпе.
R> Вдобавок -- почему мучаться? Сложную вычислительную логику целесообразнее реализовать на С++
Это и будет "мучаться". Шарп значительно проще и прозрачнее сей.
R> а просто сложную -- на Хаскеле. Правда в отношении последнего .Net даёт надежду на простую и безболезненную интеграцию с остальным кодом. За это --
Ну, если уж про интеграцию, то C++ грех жаловаться. Интегрироность по самое нехочу.
dad>>Помоему даже беглый взгляд показывает, что ява превосходит .net во всех остношениях.
ГВ>Ты только очень громко этого не говори.
У Явы, по-моему, есть только два серьёзных преимущества:
— накоплено много кода, программистов и общей инерции
— есть реальная переносимость для мощных серверов
dad>>Сказывается академический , а не коммерческий подход.
Вообще-то Ява — более уважаемый в академических кругах язык. Его в любом серьёзном американском универе учат.
ГВ>Да здесь ещё много тем подняться может. А о Java, ИМХО, не упомянуть просто не получится. Куда ж мы без неё в контексте коммуникаций.
А что, в Яве навороченые комуникации? Поделись, товарищ, ты, видно разбираешься в вопросе. Сделай краткий обзорчик для многочисленных дотнетовцев.
