.NET - против EJB

Ответ 1

WCF в .Net 3.5 является наиболее похожим, если вы не пытаетесь использовать CMP. Хотя он позволяет конечным точкам обслуживания для типов SOAP, он также позволяет удалять двоичные файлы.

Ответ 2

Важность определения терминов

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

Вы можете посмотреть на сопоставимые технологии в .NET, если это то, что вы после - технические возможности модели компонентов.

С другой стороны, некоторые люди используют "EJB" в качестве термина, чтобы свободно ссылаться на J2EE (или Java EE?). В этом случае это относится не только к компонентной модели, но к набору связанных технологий Java, обычно связанных с серверной приложений, включая компонентную модель. Это может включать даже набор инструментов, которые, конечно же, только касательно связанной с моделью компонента. Если это сравнение, то это более точно описано как "J2EE против .NET".

Другие люди могут использовать даже более сумасшедшее определение для EJB для включают такие функции, как возможности веб-сервисов, связь REST/XML или другой материал, который строго находится за пределами Java EE или EJB. Другими словами, когда они говорят "сравнить EJB с .NET", они действительно означают сравнение "серверных платформ Java на стороне сервера .NET". Последнее кажется мне гораздо более практичным сравнением, чем сравнение, например, компонентных моделей.

При проведении сравнений важно четко понимать, что именно сравнивается.

EJB - модель компонента

В EJB вы определяете объект и отмечаете его как сеанс Bean или объект Bean. Там также последнее дополнение Message Driven Bean. Три ароматизаторы компонента в EJB. Сессия Bean получает активацию - как она начинается и, возможно, "пассивируется" во времена высоких ресурсов конфликт на сервере/контейнере. СБ также получает удаленных служб.

Основная идея состоит в том, чтобы определить объект, а затем приложить к нему атрибуты, либо через дескриптор развертывания, либо через атрибуты в коде, аналог которого называется annotations в Java.

Ближайшая вещь к сеансу EJB Bean - это объект .NET. В любом .NET приложения, вы можете пометить объект атрибутами транзакции, просто как EJB SB. Вы можете сделать это удаленным, если хотите, с .NET. Удаленные и дополнительные атрибуты. Вне COM + отсутствует технология пассивации в .СЕТЬ;.NET просто игнорирует объединение как общую интересную вещь в-памяти, и, как следствие, нет никакого подхода к активации/пассивации в .NET, как есть с EJB.

sidebar # 1: это не совсем так. В .NET возможности Workflow предоставляют возможность иметь длительные действия, которые могут и будут пассивироваться и повторно активироваться. Но Workflow - это отличная метафора из "серверных объектов" или "служб", которая является центральной точкой большинства серверных архитектур приложений, использующих .NET.

sidebar # 2: Раньше считалось, что разработчики серверных платформ думали, что все захотят использовать объединение объектов, чтобы быть более эффективными. Теперь выясняется, что JVM и .NET CLR достаточно быстры для создания объектов, а памяти достаточно много, что в общем случае объединение объектов нецелесообразно. Он больше не интересен для общего случая, хотя он по-прежнему платит хорошие дивиденды за дорогие объекты, такие как соединения с базой данных.

Как и в EJB, в .NET вы можете прикрепить безопасность атрибуты объекту, позволяющие ему запускать или не запускать на основе личность вызывающего лица или другие "доказательства".

Сущность Beans - другое животное. Хотя настойчивость и в большинстве практических путеводителей рекомендация состоит в том, что entity Bean не выставлять удаленный интерфейс. Вместо этого рекомендация требует session Bean для вызова объекта Bean. Поэтому давайте просто рассмотрим EB как постоянные объекты.

В .NET здесь есть несколько альтернатив. LINQ-to-SQL дает один опция - с ORM и службами сохранения. Объект ADO.NET Рамки, возможно, более сопоставимые технологии. Конечно, все остальные службы в .NET - безопасность транзакций и удаленное взаимодействие и т.д. - также может быть применяется к объектам, использующим ADO.NET Entity Framework или LINQ.

С другой стороны, в зависимости от того, где ваш акцент делается на EJB зонтик, могут быть лучшие сопоставимые. Если вы в основном используете EJB для удалением - и с появлением REST, SOAP и других легких протоколов, почти никто не делает этого больше, насколько я могу судить, - тогда более сопоставимым в .NET является WCF.

Наконец, сопоставимые с EJB MDB компоненты .NET Queued.

Удаление EJB

Есть несколько общих аспектов для всех этих типов EJB - таких как удаленные интерфейсы. На самом деле большинство архитекторов рекомендуют вам не распространять свои EJB. Другими словами, они препятствуют людям использовать удаленный аспект, который так часто обсуждается. Вместо этого сервлет должен вызывать EJB, который является локальным, а не ссылаться на удаленный компьютер. Это Fawler First Law: не распространяйте свои объекты.

С другой стороны, иногда вам нужно.
WCF - это среда связи в .NET и является аспектом в .NET, который наиболее сопоставим с удалением EJB. Но они не эквивалентны. WCF - это универсальная платформа для удаленной связи, поддерживающая синхронизацию и асинхронную передачу данных, множество протоколов и расширяемую модель транспорта и канала, в то время как дистанционное управление EJB довольно ограничено.

Начиная с EJB правильный подход?

EJB ничего не говорит (насколько мне известно) о веб-сервисах или REST, или управленческие или облегченные рамки, или даже HTML, или инструменты разработчика. Запуск сравнение с "EJB vs blank" искусственно ограничивает обсуждение немного. Он ставит обсуждение таким образом, который может не быть оптимальный.

В EJB ничего нет, чтобы обрабатывать метафору HTML-страницы. Вы получаете это в сервлетах или одном из своих кузенов (портлеты и т.д.), Некоторые из которых находятся в J2EE. Но, строго говоря, вывод HTML не рассматривается в EJB.

Теперь, возможно, вы намереваетесь одно из более экспансивных определений EJB. С этой целью J2EE теперь добавила веб-службы в спецификацию. Но даже в этом случае я не уверен, насколько уместно рассмотреть спецификацию, с множеством дополнительных Java-фреймворков для веб-сервисов SOAP и REST.

Аналогично, если вы хотите рассмотреть возможности пользовательского интерфейса, такие как портлеты, сервлеты и AJAX, и сравнить их с эквивалентами .NET, то вы переместились далеко за пределы EJB и J2EE и на серверную Java в целом.

Это возвращается к моему предыдущему моменту - будьте ясны и точны в своем уме о том, что вы заинтересованы в изучении или сравнении.

Спецификации EJB и J2EE были амбициозными - попытка определить рамки для серверных приложений. Но всегда существовало временное отставание от того, что делают разработчики, что говорит спецификация, и то, что предлагали поставщики. Вы знаете, может быть, было однолетнее отставание между окончанием новой версии спецификации J2EE и выпуском совместимого сервера от IBM.

Из-за этого это оказалось своего рода искусственным, после-фактом. Спектр описывал вещи, которые люди уже делали. Появились такие вещи, как Spring, и J2EE ничего не говорил о них. В течение долгого времени J2EE нечего было сказать о REST или веб-сервисах или AJAX. (Даже сейчас, он говорит что-нибудь о AJAX? Я не знаю.)

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

Другими словами - предположим, что одним из ваших требований является то, что приложение будет доставлено через браузер, и оно будет реагировать на AJAX. В этом случае вам придется рассмотреть jQuery, и это нигде не описано в J2EE или EJB. Рамки AJAX доступны в различных продуктах (как Java, так и .NET). Например, Visual Studio использует jQuery для материала ASPNET AJAX. Но придерживаться спецификаций вроде промахивает этот материал.

Нижняя линия

Суть в том, что любое приложение, которое вы создаете с помощью EJB, может быть встроено в .NET, и наоборот.

Я думаю, что сравнение, подобное "EJB vs .NET", может быть интересно как академическое обсуждение, но если вы хотите получить практическое представление о том, какая технология используйте, где, тогда вам нужно думать немного по-другому.

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

Ответ 3

Можно легко утверждать, что Spring.NET...

Spring становится нормой на стороне Java, либо в дополнение к JavaEE/EJB, либо просто заменяет ее. Многие из концепций в Spring очень похожи на JavaEE/EJB, но просто лучше. Spring.NET - это, очевидно, реализация .NET.

Помимо этого, я не мог предложить ничего другого, поскольку я не активно использовал .NET в годах...

Ответ 4

много функциональных возможностей EJB уже является родным в .net(т.е. транзакции базы данных), но есть пространство имен корпоративных служб, которое также предоставляет множество функций.