java - .NET - 与 EJB

Question

.net 中 EJB（Enterprise Java Beans）的可比技术是什么？

Answer 1

术语的定义很重要

在进行比较时，术语的定义很重要。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 Remoting 和更多属性使其可远程化。在 COM+ 之外，.NET 中没有钝化技术；.NET 只是忽略了池作为与内存对象有关的通常有趣的事情，因此没有像 EJB 那样在 .NET 中进行激活/钝化的方法。

---

侧边栏#1：这并不完全正确。在 .NET 中，工作流功能提供了一种工具来进行长时间运行的活动，这些活动可以并且将被钝化和重新激活。但是，工作流是与“服务器端对象”或“服务”截然不同的隐喻，后者是大多数使用 .NET 的服务器端应用程序架构的中心点。

---

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

---

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

实体豆是一种不同的动物。虽然可以将持久性和远程处理结合起来，但在大多数实用指南中，建议实体 bean 不公开远程接口。相反，建议要求会话 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 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 选项等。然后根据优先级列表权衡选项。

Answer 2

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

Answer 3

人们很容易争论 Spring.NET ......

Spring 正在成为 Java 方面的规范，无论是对 JavaEE/EJB 的补充还是完全取代它。Spring 中的许多概念与 JavaEE/EJB 非常相似，但更好。Spring.NET 显然是它的 .NET 实现。

除此之外，我无法提出任何其他建议，因为我多年来没有积极使用过 .NET...

Answer 4

许多 EJB 功能在 .net 中已经是原生的（即数据库事务），但企业服务命名空间也提供了很多功能。