.NET与EJB的比较

Question

.NET与EJB的比较

java.netejb

24

在 .net 中，与 EJB（Enterprise Java Beans）相似的技术是什么？

- JMSA

4个回答

3

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

- stevedbrown

1

有人可以很容易地争辩说Spring.NET...

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

除此之外，我没有别的建议，因为我已经多年没有积极使用.NET了...

- James

0

许多EJB功能已经在.NET中本地化（例如数据库事务），但是企业服务命名空间也提供了很多功能。

- Russ Bradberry

2

EJB事务并不完全等同于数据库事务（当然，JDBC支持数据库事务），但这只是纠结细节。 - Esko

.NET事务远远超过数据库事务，因此来自Russ的“即”非常重要。 - boj

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Cheeso · Accepted Answer

术语的定义很重要

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

如果您想要比较可比的.NET技术-组件模型的技术能力，您可以查看它们。

另一方面，一些人将“EJB”作为一个术语，泛指J2EE（或Java EE？）。在这种情况下，它不仅仅是一个组件模型，而且是一组相关的Java技术，通常与服务器端应用程序相关联，包括组件模型。这甚至可能包括工具集，当然只是与组件模型有关的间接联系。如果是这种比较，那么更适合描述为“J2EE vs. .NET”。

还有其他人可能使用更模糊的EJB定义，包括Web服务功能、REST/XML通信或其他严格属于Java EE或EJB本身之外的内容。换句话说，当他们说“比较EJB和.NET”时，他们实际上是要比较“服务器端Java平台和服务器端.NET”。后者对我来说是一个更实际的比较，而不是比较组件模型。

在进行比较时，清楚地说明正在比较的内容非常重要。

EJB-组件模型

在EJB中，您定义一个对象并将其标记为Session Bean或Entity Bean。还有消息驱动的豆子的后期添加。EJB中的三个组件类型。会话Bean获取激活-启动方式以及在服务器/容器资源争用时可能“停用”。SB还会获得安全性和远程服务。

基本思想是定义一个对象，然后通过部署描述符或代码中的属性将属性附加到该对象，其类似于Java中的annotations。

与EJB Session Bean最接近的是.NET对象。在任何.NET应用程序中，您都可以使用事务属性标记对象，就像使用EJB SB一样。您可以使用.NET Remoting将其设为可远程，以及更多属性。在COM+之外，.NET没有停用技术。NET只是将池化视为与内存中对象一般有趣的东西而忽略了它。因此，在.NET中没有方法来执行激活/停用，就像在EJB中一样。

侧边栏 #1：这并不完全正确。在.NET中，工作流能力提供了一个设施，可以拥有长时间运行的活动，并且会被暂停和重新激活。但是，工作流是一个独特的隐喻，与使用.NET的大多数服务器端应用程序体系结构的“服务器端对象”或“服务”的中心点不同。

侧边栏 #2: 曾经，服务器端平台的设计师们认为每个人都想使用对象池来提高效率。现在，事实证明JVM和.NET CLR在创建对象方面已经足够快，并且内存也足够丰富，因此，一般情况下，对象池不再实用。尽管对于昂贵的对象，如数据库连接，仍然有很好的回报。

与EJB类似，你可以在.NET中向对象附加安全属性，以允许它根据调用者的身份或其他"证据"运行或不运行。

实体Bean是一个不同的概念。虽然持久性和远程操作可以结合使用，但在大多数实用指南中，建议实体Bean不要公开远程接口。相反，建议使用会话Bean来调用实体Bean。因此，我们只需将EB视为持久化对象。

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

另一方面，取决于您在EJB范畴中的重点，可能会有更好的可比较性。如果您主要使用EJB进行远程操作-随着REST、SOAP和其他轻量级协议的出现，我认为几乎没有人再这样做了-那么在.NET中更好的可比较性是WCF。

最后，与EJB MDB相对应的是.NET队列组件。

EJB远程操作

这些类型的EJB都有一些共同点，比如远程接口。实际上，大多数架构师建议不要分发你的EJBs。换句话说，他们不鼓励人们使用常见的远程方面。相反，一个servlet应该调用一个本地的EJB，而不是在远程机器上调用一个EJB。这是Fowler's First Law：不要分发你的对象。

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

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

就我所知，EJB没有关于Web服务、REST、管理或轻量级框架、甚至HTML或开发工具的任何说明。从“EJB vs 空白”开始比较，有点人为地限制了讨论。它以一种可能不太理想的方式框定了讨论。

在EJB中没有处理HTML页面隐喻的内容。你可以在servlet或其兄弟姐妹（portlets等）中找到这些内容，其中一些在J2EE中。但严格来说，HTML输出并没有在EJB中涵盖。

现在，也许你想要更广泛的EJB定义。为此，J2EE现在已将Web服务添加到规范中。即使如此，考虑到基于SOAP Web服务和REST的Java附加框架的多样性，我不确定它是否相关。

同样地，如果您想考虑UI功能，如Portlets、Servlets和AJAX，并将它们与.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在ASPNET AJAX中使用jQuery。但是坚持规范会忽略这些东西。

底线是，您使用EJB构建的任何应用程序都可以在.NET中构建，反之亦然。

我认为像“EJB vs .NET”这样的比较可以作为学术讨论感兴趣，但如果您想了解在何处使用哪种技术的实际见解，那么您需要以不同的方式思考。

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