.NET - vs EJB

术语的定义很重要

在进行比较时，术语的定义很重要。EJB 是一个组件模型。它为在容器中运行的组件定义了持久性、事务、远程处理、激活和安全功能（可能还有其他功能）。

您可以查看 .NET 中的可比技术，如果这是您所追求的 - 组件模型的技术功能。

另一方面，有些人使用“EJB”作为术语来松散地指代J2EE（或Java EE？）。在这种情况下，它不仅指组件模型，还指通常与服务器端应用程序关联的一组相关的 Java 技术，包括组件模型。这甚至可能包括工具集，当然，这些工具集仅与组件模型切线相关。如果这是比较，那么它被更恰当地描述为“J2EE与.NET”。

还有一些人可能会对EJB使用更模糊的定义，以包括诸如Web服务功能，REST / XML通信之类的东西，或者其他严格超出Java EE或EJB本身的东西。换句话说，当他们说“比较EJB和.NET”时，他们实际上意味着比较“服务器端Java平台和服务器端.NET”。在我看来，后者比比较组件模型更实际。

在进行比较时，重要的是要清楚要比较的内容。

EJB - 组件模型

在 EJB 中，定义一个对象并将其标记为会话 Bean 或实体 Bean。还有消息驱动的Bean的后期添加。EJB中组件的三种风格。会话 Bean 获得激活 - 在服务器/容器上资源争用频繁时，它是如何启动的，并可能被“钝化”。SB 还获得安全和远程处理服务。

基本思想是定义一个对象，然后通过部署描述符或代码内属性（其模拟在 Java 中称为注释）附加到该对象。

最接近 EJB 会话 Bean 的是 .NET 对象。在任何 .NET 应用程序中，都可以使用事务属性标记对象，就像 EJB SB 一样。如果您愿意，可以使用 .NET 远程处理和更多属性使其可远程处理。在 COM+ 之外，.NET 中没有钝化技术;.NET 只是忽略了池化，因为池化是处理内存中对象的一件非常有趣的事情，因此在 .NET 中没有像 EJB 那样进行激活/钝化的方法。

侧边栏#1：这并不完全正确。在 .NET 中，工作流功能提供了一种工具，用于处理可以并且将要被动和重新激活的长时间运行的活动。但是，工作流与“服务器端对象”或“服务”是大多数使用 .NET 的服务器端应用程序体系结构的中心点。”

侧边栏#2：过去，服务器端平台的设计者认为每个人都希望使用对象池以提高效率。现在事实证明，JVM 和 .NET CLR 在创建对象方面足够快，并且内存足够丰富，通常，对象池没有实际用途。对于一般情况来说，它不再有趣，尽管它仍然为数据库连接等昂贵的对象带来了丰厚的回报。

与 EJB 一样，在 .NET 中，您可以将安全属性附加到对象，以允许它根据调用方的身份或其他“证据”运行或不运行。

实体豆是一种不同的动物。虽然持久性和远程处理可以结合使用，但在大多数实用指南中，建议实体 Bean 不要公开远程接口。相反，该建议要求会话 Bean 调用实体 Bean。因此，让我们将 EB 视为持久性对象。

在.NET中，这里有很多替代方案。LINQ-to-SQL提供了一个选项 - 使用ORM和持久性服务。ADO.NET 实体框架可能是一种更具可比性的技术。当然，.NET 中的所有其他服务（事务安全性和远程处理等）也可以应用于使用实体框架或 LINQ ADO.NET 的对象。

另一方面，根据您在EJB保护伞中的重点位置，可能会有更好的可比性。如果你主要使用EJB进行远程处理 - 并且随着REST，SOAP和其他轻量级协议的出现，据我所知，几乎没有人再这样做 - 那么在.NET中更好的可比性是WCF。

最后，与 EJB MDB 相当的是 .NET Queued Components。

EJB 远程处理

所有这些类型的 EJB 都有一些共同的方面 - 例如远程接口。实际上，大多数架构师都建议您不要分发 EJB。换句话说，它们不鼓励人们使用经常讨论的远程处理方面。相反，servlet 应该调用本地的 EJB，而不是在远程机器上调用一个 EJB。这是福勒的第一定律：不要分发你的对象。

另一方面，有时你必须这样做。
WCF 是 .NET 中的通信框架，也是 .NET 中与 EJB 远程处理最相媲美的方面。但它们并不等同。WCF 是用于远程通信的非常通用的框架，支持同步和异步、多个协议以及可扩展的传输和通道模型，而 EJB 远程处理则相当有限。

从 EJB 开始是正确的方法吗？

EJB没有说任何关于Web服务，REST，管理或轻量级框架，甚至HTML或开发人员工具的内容（ 据我所知）。开始与“EJB与空白”进行比较会人为地限制讨论。它以一种可能不是最佳的方式构建了讨论。

EJB 中没有任何东西可以处理，例如，HTML 页面隐喻。你可以在 servlet 或其表亲（portlet 等）之一中得到它，其中一些在 J2EE 中是正确的。但严格来说，HTML输出在EJB中没有涵盖。

现在，也许你打算使用 EJB 的一个更广泛的定义。为此，J2EE 现在已将 Web 服务添加到规范中。但即便如此，我不确定考虑规范有多相关，因为SOAP Web服务和REST的各种基于Java的附加框架。

同样，如果你想考虑像 Portlet、servlet 和 AJAX 这样的 UI 功能，并将它们与 .NET 的等效项进行比较，那么你已经远远超出了 EJB 和 J2EE，进入了一般的服务器端 Java。

这又回到了我之前的观点 - 在你自己的头脑中清楚和精确地了解你有兴趣检查或比较的内容。

EJB 和 J2EE 规范雄心勃勃 - 试图为服务器端应用程序定义框架。但是，开发人员正在做什么，规范所说的内容以及供应商正在交付的内容之间总是存在时间差。您知道，在 J2EE 规范的新版本最终确定和 IBM 发布兼容服务器之间可能有 1 年的滞后。

正因为如此，它最终成为一种人造的，事后。该规范描述了人们已经在做的事情。像Spring这样的东西即将问世，J2EE没有对它们说任何话。在很长一段时间里，J2EE对REST、Web服务或AJAX一无所知。（即使是现在，它对AJAX有什么看法吗？我不知道。

鉴于规范理论与开发人员实际实践的现实之间的距离，更好的方法可能是确定应用程序需求，然后将EJB和其他相关技术与要构建的应用程序的适当性进行比较。

换句话说 - 假设您的要求之一是应用程序将通过浏览器交付，并且它将具有AJAX的响应能力。在这种情况下，你将不得不考虑jQuery，而这在J2EE或EJB中没有涵盖。AJAX 框架在各种产品（Java 和 .NET）中都可用。例如，Visual Studio使用jQuery作为ASPNET AJAX的东西。但是坚持规格有点错过了这些东西。

底线

最重要的是，使用 EJB 构建的任何应用都可以在 .NET 中构建，反之亦然。

我认为像“EJB与.NET”这样的比较作为学术讨论可能会引起人们的兴趣，但是如果你想对在哪里使用什么技术有实际的了解，那么你需要以不同的方式思考。

您需要确定需求并确定其优先级 - 例如开发速度、部署成本、部署机制、工具支持、部署平台支持、语言支持、性能、UI 外观、UI 选项等。然后根据该优先级列表权衡选项。

.Net 3.5 中的 WCF 是最相似的，只要您不尝试使用 CMP 即可。虽然它允许 SOAP 类型的服务终结点，但它也允许二进制远程处理。