Re[8]: jsdk.jar
От: demo  
Дата: 27.03.02 13:15
Оценка:
Здравствуйте IT, Вы писали:

IT>Здравствуйте AndrewVK, Вы писали:


IT>>>Давай ты мне расшифруешь эти аббревиатуры и скажешь для чего они нужны, а я постараюсь привести примеры аналогов.


AVK>>Нет проблем. Начнем с более простой. JDO — Java Data Objects. Технология сериализации объектов в различные источники (обычно DB и XML) с возможностью выборочной десериализации. А главное — умеющая десериализовывать по набору условий при помощи языка похожего на SQL но для работы с объектами. Короче — механизм персистентности.

AVK>>Ничего похожего у MS пока нет.

IT>Я тоже иногда кидаюсь голословными заявлениями, потом приходится жалеть. В .NET не просто сериализация, а сериализация на сериализации и сериализацией погоняет. Возможно она реализована не так как в Java, но это не значит что хуже. Всё сериализуется по-умолчанию, если есть желание, то можно этим довольно гибко управлять простыми атрибутами без всяких языков. Но если и этого не достаточно, то перекрывай ISerializable и вытворяй что хочешь. Для сохранения/восстановления объектов предназначены форматеры, сейчас их есть для binary и xml. Никто тебе не мешает нарисовать свой и сохранять как тебе хочется.


AVK>>EJB — Enterprise Java Beans, ключевая технология J2EE. Это сервер приложений. Главное отличие от других подобных технологий — более глубокое взаимодейстиве с объектами. К примеру EJB сервер сам загружает, выгружает и инициализирует бизнес-объекты, активно их кеширует, обеспечивает безопасность, механизм транзакций, в т.ч. и распределенных, пул соединений с SQL сервером, балансировку нагрузки и работу в кластерах.


IT>Насколько мне известно, там внутри под всем этим хозяйством лежит CORBA. Или я ошибаюсь? MS рекомендует для этих целей использовать COM+. С одной стороны он тесно интегрирован с ОС, с другой с .NET. Все перечисленные тобой возможности в нём имеются.


AVK>>Существуе механизм полностью автоматической загрузки\выгрузки объектов, когда контейнер сам создает запросы к БД, выполняет их и результат предоставляет разработчику. Ну и наконец это полноценный Object-Relational преобразователь реализующий отношения 1-1, 1-n, n-1, n-n. Самое похожее на это у MS — COM+ и serviced components, но они не умеют многое из того что могут EJB-сервера.


IT>Этого я не припомню, но пока и не соображу зачем это надо.


IT>>>Только сразу предупреждаю, как я уже говорил, .NET дополняет Win32 и возможно некоторые вещи эффективнее реализовывать на последней.


AVK>>Э нет, так не пойдет. Идеология .Net такова что следует по возможности максимально избегать legacy интерфейсов, особенно Win32 API. И не только для переносимости. При этом вся система anti dll-hell идет нафик. Да и за что тогда боролись? Чтобы все писать на Win32? А нафига тогда дотнет?


IT>Ещё раз повторюсь. .NET не отменяет Windows, более того, это было бы просто самоубийство. Скороее всего, постепенно большинство сервисов, предоставляемых Windows будут заменяться на собственные. Но это будет происходить эволюционно. И это правильно. Переход должен быть постепенным и должна быть обеспечена интеграция с существующими технологиями. В частности для написания объектов COM+ в .NET совсем не надо прибегать к использованию WinAPI, всё делается интерфейсами и атрибутами.


AVK>>>>При чем здесь все возможности. Вот скажи для примера — если мне LinkedList нужен — мне его ручками писать или ArrayList пользовать? Ни Queue ни Stack мне не подходят ввиду необходимости удалять элементы из середины.


IT>>>А чем ArrayList не подходит?


AVK>>Сделаем проще. Вот исходник


IT>[skip]


IT>Тогда рассказывай что такое LinkedList, если ни список ни коллекция тебе не подходит.


IT>>> А про beta2 это не честно. Это ж бэта, она глючить должна по определению


AVK>>Думаешь есть существенная разница между бетами и релизами? То-то MS не успел выпустить релиз дотнета уже сервис пак к нему лежит.


IT>То что я в бессильной злобе пытался решить на бете в релизе было пофиксено. А быстрые сервис-паки это неплохо, работают ребята



Да как-то криво .NET работает с COM+:
1. распределенные транзакции не поддерживаются
2. JIT активация не работает
3. pooling не работает
4. пул подсоениения к SQL серверу через SQLConnection не работает
5. с настройкой безопсности какие-то траблы
Правда 2, 3 реализовано в CLR

И вообще:

The Microsoft speaker shocked me by saying
that COM+ services in .NET are just for backward compatibility and we
should avoid using them. For example use ADO.NET manual transactions
instead of COM+ automatic transactions and System.Messaging for
asynchronous communication. He also said that the COM+ support will either
be **removed** or there will be **no enhancements** to it in future
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.