У MS в принципе это COM+...
В .Нете смотри System.EnterpriseServices на предиет работы с COM+...

Ну один-в-один никто и необещал ;-)
Просто в плане что одно может "закрывать" другое, а способ реализации и подход конечно разный.

P.S.
CMP достойный только в EJB 2.0 появился. Да и сам он только делает (дает возможность) посути легкость разработки и больше ничего. Если будет более продвинутая логика, то без BMP никуда...

Ну а что там такого отстойного то? а?

Ну как тебе сказать... Написание хорошей грамотной структуры базы, хорошо работающих запросов и проч. - не такая уж и сложная работа, требующая, однако, высокой квалификации. Как DBA, меня сильно возмущает кривой код/кривая структура/неоптимальное использование возможностей СУБД. CMP, в данном случае, пытается неуклюже скрыть уровень работы с СУБД ради обеспечения никому не нужной совместимости с различными хранилищами и, якобы, упрощения труда девелоперов. Это глупости. Коммерческий продукт должен быть написан профессионалами, а не лентяями и недоученными студентами.

Неспорю, что нужны мозги в первую очередь...
CMP для себя я понимаю в первую очередь как исключение "ненужного" кода.
Типа: setString(... getString... для SELECT/UPDATE/INSERT/DELETE... и без всяких там паттернов типа DAO & Co.
Посути это стандартые операции один-в-один над "простыми данными" вот и все. Только дальше ты работаешь не с ДБ а с объектами...

В целом, entity beans склоняют к максимизации выноса логики обработки информации в аппсервер, что тоже, разумеется, чистой воды глупистика. Кэширование бинов аппсервером - ненужная дикость, нормальные СУБД обладают гораздо более развитыми механизмами кэширования данных. Выигрыш тут может быть только за счёт снижения времени отклика (т.е., минус сеть, минус запрос туда-сюда), но это очень мало даёт для реальной работы.

В первую очередь это все зависить от задачи, где/что и как делать.
Скажу лишь, что с объектами работать иногда куда проше (а за ними может стоять не только "голые" таблицы), чем "чисто" c PL/SQL процедурами, как пример. Просто слезы появляются, когда видишь типа: get_customer i get_customer2 процедуры....

P.S.
По своему опыту не приходилось использовать (кроме тестов) CMP.
BMP устраивала по всем параметрам, хотя можно было кое-какие "куски" и вынести в CMP (да только неособо хотелось возиться со всеми настройками).

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

О-дааа.... покруче будет... :-) если под ним "лепить", лишь бы было...

Согласен. Но культуру разработки надо держать. Сложную логику удобно держать в объектах, но данные получать не из entity beans, а ручками.

Ага. Только вопрос, для чего эти данные нужны?
Если для того что бы "отобразить" только, то конечно, зачем entity beans плодить, те же самые VO (Value objects) для этого есть...
Если я правилильно понял your minds ;-)

P.S. А вот ради спортивного интереса - как в CMP использовать оракловский контекстный (interMedia Text) индекс?

Ммм... Не скажу, никогда такое не пробывал. Скорее всего это зависит от конкретного провайдера и его наворотов на этот счет.

2 Артем1
> Я все еще не успокоился :)
:-)

> Прочитал эту и вот эту статьи.

> Нифига не понял. В первой вроде все похоже на COM+ под MTS-ом. Но не
> рекомендуют использовать. Предложенную альтернативу я не понял. Как в
> .NET создать компонент, который бы управлялся MTS-ом? Что-бы он за
> меня держал и управлял пулом объектов, транзакциями и т.п.?

смотри System.EnterpriseServices в MSDN'e.
точнее System.EnterpriseServices.ServicedComponent
кстати в статье 1 об этом говорится :-)

> Вторая статья вроде-как начала прояснять, но в конце опять все
> запуталось :(
> Вроде то, что искал, но не понятно, под управлением чего это работает?
> Там советовали читать дальше Microsoft .NET Framework Component
> Services.
> Где это? Не подкинет ли кто ссылочку, пли
Ненадо все "в одну корзинку" гребсти.
2-ая статья об Microsoft .NET Remoting....
-------------
3. В службах .NET-компонентов
Объекты .NET Remoting можно размещать в инфраструктуре служб .NET-компонентов, что позволяет использовать такие возможности служб COM+, как транзакции, JIT и создание пулов объектов.

Дополнительную информацию см. в Microsoft .NET Framework Component Services, Part 1.
--------------
А это посути первое... :-)
а-ля System.EnterpriseServices.ServicedComponent