Завтра подкину интересных статей.

LSL
ДА нет будь добр оставь статей для себя .

LSL

Сообщение от :
Советую прочесть хотя бы парочку обзорных статей из интернета, а ещё лучше купите книгу! Потом продолжим разговор

Мы же профи, какие там обзорные статьи! Нам техническую доку надо читать.

Сообщение от :
Читай MSDN.

То есть, не могем сказать! А еще спорим...

zss_vrn
Доступ к БД в .net осуществляется через ADO.Net. Объектная модель по сравнению с ADO сильно переработана. За доступ к конкретной базе отвечает конкретный класс дата провайдеров. Есть
The SQL Server .NET Data Provider - понятно для кого
The OLE DB .NET Data Provider
The ODBC .NET Data Provider
A managed provider for retrieving XML from SQL Server 2000

Технология ADO.Net очень удобная и быстро работает. Теперь dataset (объект пришедший на смену recordset) может сразу содержать несколько таблиц, с прописанными отношениями между ними (типа foreign keys).

На смену DCOM пришла технология .NET Remoting и Web services. Поддержка COM тоже есть. Предусмотрены стандартные сериализаторы объектов - двоичный и XML.

Alex__G Правда то что говорят будто ADO.NET быстрее классического ADO ? Не знаешь ?

LSL
Не будь голословным, ссылочку пожалуйста. Я не мог такого говорить
Что подчистил уже ?

LSL
Слышал то же самое, но лично не пробовал. Читал, что AdO.NET работает быстрее DbExpress где-то на 10% (не с SQL Server - с ним вообще все летает). Приеду домой, протестирую.

zss_vrn
Да, в ADO.NET практически то же самое. Есть два способа работы с данными - отлюченные датасеты и однонаправленные query. В первом случае используется объект DataAdapter (и создается dataset), а во втором DataReader.

Про .Net remoting подробно писать здесь, наверное, нет смысла. У тебя есть MSDN? Если нет - то я могу послать тебе статейку описывающую архитектуру в общем виде.

Про компонентную модель пока не знаю. JVM нет уже в XP - что не мешает скачать ее с сайта Sun'a и пользоваться. Напрочь вырубить ее невозможно.
Про Longhorn еще рано что-то говорить. Пока она выйдет, многое может измениться.

Gartner советует компаниям придерживаться консервативной политики и не рисковать с применением .Net для критических приложений. Кроме того, по ее оценкам, в течение ближайших четырех лет соотношение Visual С++ и C# станет равно 2:3. Gartner отмечает, что эти разработчики будут использовать С++ на уровне системного программирования, т. е. очень значительная часть разработчиков останется верна старой платформе. Не говоря уже об использующих Java.

Это мнение не только Гартнера.

Giga Information Group. В ближайшие два года .Net захватит лишь около 35% рынка корпоративных разработок, оставив основную долю рынка в руках J2EE. Решающими факторами станут технологическая зрелость и гибкость в работе с различными поставщиками. То есть в двух из трех основных факторах успеха Java имеет перевес. "Потенциальным пользователям следует учитывать масштабируемость, функции восстановления после сбоев, "привязку" к поставщикам и технические требования отдельных приложений, - заявил вице-президент Giga Ренди Хеффнер. -- .Net несомненно укрепляет платформу Microsoft и позволяет ей принимать более активное участие в корпоративном рынке, однако не настолько, чтобы значительно изменить баланс. Другими словами, .Net не станет концом J2EE".

Еще от гартнера
Gartner estimates there's a 50% chance that Longhorn will be available in 2006, and a 40% chance it will be available in 2007.

zss_vrn
10% что выйдет раньше

zss_vrn
Кто-то тут говорил о конце COM...

Я.

Компонентную модель - COM заменит "компонентная модель" - .NET

... и она не подчиняется законам логики, что видно из предыдущих споров.

Ты о чём ? Я где-то был не логичен ?

LSL
Доплюнет и переплюнет
Несклько пристрастное сравнение. Непонятно, что за Java? J2ME или J2SE, а может быть J2EE? Если последняя, тогда почему про EJB и все что связано с этой технологией забыли? Если нет - тогда сравнение просто некорректно. Есть много вопросов к авторам. Такое впечатление, что когда удобно, сравнивают с Java (опять же, какой версией?), когда удобно с Корбой.
В общем, я бы не стал всерьез рассматривать эту статью.

Межплатформенной интеграции пока нет. Чтобы перенести .NET на другие ОС, нужно перенести в эти ОС кусок Windows. В общем, посмотрим, что у ребят получится, и какой % возможностей .NET будет реализован в Linux. А какой - нет, и что войдет в эти нереализованные возможности. Вот тогда и вернемся к этому разговору.

zss_vrn
Все-таки найди обзор .NET remoting. Прямого аналога IDL нет, но есть файл XML, описывающий как соединиться с удаленным объектом. И при соединении среда клиента получает метаданные удаленного объекта. Как насчет раннего связывания - не знаю, может быть можно импортировать метаданные сборки, в которой находится удаленный объект. Я сам детально не разбирался.

В общем, советую, ознакомься. Многие вопросы про COM и межкомпьютерное взаимодействие станут ясны.

LSL
Слабый и глючный - это все равно что нет. Особенно если идет сравнение с J2ee.
Планы могут так и остаться планами. Судить будем по результатам, и не раньше появления готовых версий (а не 0.28-0.29).
API ос разные. Для чего-то может просто не оказаться аналога. Сейчас кстати .NET работает только с IIS. Это значит что его тоже будут портировать под Linux?

.NET remoting это не веб-сервисы. Хотя общие места есть:

For metadata, .NET Remoting relies on the common language runtime assemblies, which contain all the relevant information about the data types they implement, and expose it via reflection.

Хотя WSDL описание метаданных может генерироваться (для случая HTTP/SOAP), конфигурационный файл остается конфигурационным файлом. Это не WSDL. Так и называется: remoting configuration file.