.NET - против EJB
https://stackoverflow.com/questions/1040840
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Какова сопоставимая технология EJB (Enterprise Java Beans) в .net?
Решение
WCF в .Net 3.5 наиболее похож, если вы не пытаетесь использовать CMP. Хотя он разрешает конечные точки служб для объектов типа SOAP, он также позволяет выполнять двоичное удаленное взаимодействие.
Другие советы
Определение терминов имеет важное значение
При проведении сравнений важно определение терминов.Объект находится в компонентная модель.Он определяет сохраняемость, транзакцию, удаленное взаимодействие, активацию и возможности безопасности (и, возможно, другие) для компонентов, которые работают внутри контейнера.
Вы можете посмотреть на сопоставимые технологии в .NET, если это то, что вам нужно технические возможности компонентной модели.
С другой стороны, некоторые люди используют "EJB" как термин для общего обозначения J2EE (или Java EE?).В этом случае это относится не к просто к компонентной модели, но к набору связанных технологий Java, обычно связанных с серверными приложениями, включая компонентную модель.Это может даже включать наборы инструментов, которые, конечно, связаны с моделью компонента только косвенно.Если это является ли сравнение , тогда оно более точно описывается как "J2EE против.NET".
Тем не менее, другие люди могут использовать еще более размытое определение для EJB, чтобы включить такие вещи, как возможности веб-служб, связь REST / XML или другие материалы, которые строго выходят за рамки Java EE или собственно EJB.Другими словами, когда они говорят "сравнить EJB с .NET", они на самом деле имеют в виду сравнение "серверных платформ Java с серверной .NET".Последнее кажется мне гораздо более практичным сравнением, чем сравнение, скажем, моделей компонентов.
При проведении сравнений важно четко представлять, что именно сравнивается.
EJB - компонентная модель
В EJB вы определяете объект и помечаете его как компонент сеанса или сущность Bean.Существует также позднее добавление компонента, управляемого сообщениями.Три ароматы компонент в EJB.Сессионный компонент получает активацию - как он запускается и, возможно, "пассивируется" во времена больших ресурсов конфликт на сервере / контейнере.SB также получает услуги безопасности и удаленного взаимодействия.
Основная идея состоит в том, чтобы определить объект и затем присоединить к нему атрибуты, либо через дескриптор развертывания, либо через атрибуты в коде, аналог для которого вызывается аннотации на языке Java.
Самая близкая вещь к сеансовому компоненту EJB - это .NET-объект.NET.В любом приложении .NET вы можете пометить объект атрибутами транзакции, точно так же, как EJB SB.Вы можете сделать его удаленным, если хотите, с помощью .NET Remoting и других атрибутов.За пределами ком+ нет технология пассивации в .Объем;.NET просто игнорирует объединение в пул как обычно интересную вещь, связанную с объектами в памяти, и в результате в .NET нет такого подхода к активации / пассивации, как в EJB.
боковая панель №1:это не совсем так.В .NET функция Workflow предоставляет средство для выполнения длительных действий, которые могут и будут пассивироваться и повторно активироваться.Но рабочий процесс - это отличная метафора от "серверных объектов" или "сервисов", которые являются центральной точкой большинства серверных прикладных архитектур, использующих .NET.
боковая панель №2:Раньше разработчики серверных платформ думали, что все захотят использовать объединение объектов, чтобы быть более эффективными.Теперь оказывается, что JVM и .NET CLR достаточно быстры при создании объектов, а памяти достаточно много, так что в целом объединение объектов в пул не имеет практического применения.Это больше не интересно для общего случая, хотя по-прежнему приносит хорошие дивиденды для дорогостоящих объектов, таких как подключения к базе данных.
Как и в EJB, в .NET вы можете прикрепить атрибуты безопасности к объекту, чтобы разрешить ему запускаться или не запускаться на основе идентификатора вызывающего объекта или других "доказательств".
Сущностные бобы - это совсем другое животное.Хотя сохранение и удаленное взаимодействие можно комбинировать, в большинстве практических руководств рекомендуется, чтобы компонент entity bean не предоставлял удаленный интерфейс.Вместо рекомендации звонки сеансный компонент для вызова лица в зернах.Итак, давайте просто рассмотрим EB как постоянные объекты.
В .NET здесь есть множество альтернатив.LINQ-to-SQL предоставляет один вариант - с ORM и службами сохранения.Платформа ADO.NET Entity , возможно, является более сопоставимой технологией.Конечно, все остальные сервисы в .NET - безопасность транзакций, удаленное взаимодействие и т.д. - Также могут быть применены к объектам, использующим ADO.NET Entity Framework или LINQ.
С другой стороны, в зависимости от того, на чем вы акцентируете внимание в EJB umbrella, могут быть лучшие сравнения.Если вы в основном используете EJB для удаленного взаимодействия - а с появлением REST, SOAP и других облегченных протоколов, насколько я могу судить, этим почти никто больше не занимается, - то более сопоставимым в .NET является WCF.
Наконец, сопоставимые с EJB MDB - это компоненты .NET, поставленные в очередь.NET.
Удаленное управление EJB
Есть несколько общих аспектов для всех этих типов удаленных интерфейсов, подобных EJBs.На самом деле большинство архитекторов рекомендуют вам не распространять свои EJBS.Другими словами, они отбивают у людей охоту использовать аспект удаленного взаимодействия, который так часто обсуждается.Вместо этого сервлет должен вызывать локальный EJB, а не вызывать его на удаленном компьютере.Это Первый Закон Фаулера: Не распространяйте свои объекты.
С другой стороны, иногда вы должны это делать.
WCF - это коммуникационная платформа в .NET, и это аспект в .NET, наиболее сопоставимый с удаленным взаимодействием EJB.Но они не равнозначны.WCF - это платформа общего назначения для удаленной связи, поддерживающая синхронизацию и асинхронность, несколько протоколов и расширяемую транспортную и канальную модель, в то время как удаленное использование EJB довольно ограничено.
Является ли запуск с EJB правильным подходом?
EJB ничего не говорит (насколько я знаю) о веб-сервисах, или REST, или управлении, или облегченных фреймворках, или даже HTML, или инструментах разработчика.Начинаем сравнение с "EJB vs пустой" искусственно сдерживает дискуссию немного.Это выстраивает обсуждение таким образом, который, возможно, не является оптимальным.
В EJB нет ничего, что могло бы обрабатывать, например, метафору HTML-страницы.Вы получаете это в сервлетах или одном из их двоюродных братьев (портлеты и т.д.), Некоторые из которых находятся в самом J2EE.Но, строго говоря, вывод HTML не описан в EJB.
Теперь, возможно, вы имеете в виду одно из более широких определений EJB.С этой целью J2EE теперь добавила веб-сервисы в спецификацию.Но даже в этом случае я не уверен, насколько уместно рассматривать спецификацию, учитывая разнообразие дополнительных фреймворков на основе Java для веб-сервисов SOAP и REST.
Аналогично, если вы хотите рассмотреть возможности пользовательского интерфейса, такие как портлеты, сервлеты и AJAX, и сравнить их с .ЧИСТЫЕ эквиваленты, тогда вы продвинулись далеко за пределы EJB и J2EE и вообще перешли на серверную Java.
Возвращаясь к моему предыдущему тезису - будьте ясны и точны в своем собственном сознании относительно того, что вам интересно исследовать или сравнивать.
Спецификации EJB и J2EE были амбициозными - они пытались определить фреймворки для серверных приложений.Но всегда существовал временной лаг между тем, что делали разработчики, что говорилось в спецификации и что поставляли поставщики.Вы знаете, возможно, между завершением разработки новой версии спецификации J2EE и выпуском совместимого сервера от IBM была задержка в 1 год.
Из-за этого все получилось как-то искусственно, постфактум.Спецификация описывала то, что люди уже делали.Выходили такие вещи, как Spring, а J2EE ничего о них не говорила.Долгое время J2EE ничего не мог сказать ни о REST, ни о веб-сервисах, ни об AJAX.(Даже сейчас, говорит ли это что-нибудь об AJAX?Я не знаю.)
С учетом расстояния между теорией и спецификаций реальность из реальной практики разработчиков, лучшим подходом может быть определение требований к программе, и сравните целесообразности EJB и других сопутствующих технологий приложения, которые вы хотите построить.
Другими словами, предположим, что одним из ваших требований является то, что приложение будет доставляться через браузер и будет обладать отзывчивостью AJAX.В этом случае вам придется рассмотреть jQuery, а это нигде не описано в J2EE или EJB.Фреймворки AJAX доступны в различных продуктах (как Java, так и .NET).Например, Visual Studio использует jQuery для работы с ASPNET AJAX.Но, придерживаясь спецификаций, в некотором роде упускаешь из виду этот материал.
Итог
Суть в том, что любое приложение, которое вы создаете с помощью EJBs, может быть создано в .NET, и наоборот.
Я думаю, что такое сравнение, как "EJB vs . .NET", может быть интересным в качестве академической дискуссии, но если вы хотите получить практическое представление о том, какую технологию где использовать, тогда вам нужно мыслить немного по-другому.
Вам необходимо определить и расставить приоритеты в отношении требований, таких как скорость разработки, стоимость развертывания, механизм развертывания, поддержка инструментов, поддержка платформы развертывания, языковая поддержка, производительность, внешний вид пользовательского интерфейса, параметры пользовательского интерфейса и т.д.Затем сопоставьте варианты с этим списком приоритетов .
Можно легко поспорить Spring.NET ...
Spring становится нормой на стороне Java, либо в дополнение к JavaEE / EJB, либо полностью заменяя его. Многие концепции Spring очень похожи на JavaEE / EJB, но просто лучше. Spring.NET, очевидно, является его реализацией .NET.
Кроме этого, я не мог предложить ничего другого, так как я не использовал активно .NET в течение многих лет ...
большая часть функций EJB уже встроена в .net (то есть транзакцию базы данных), но есть пространство имен корпоративных сервисов, которое также предоставляет множество функций.
