java .NET - 与 EJB

.NET - vs EJB

提问by user366312

What is the comparable technology of EJB (Enterprise Java Beans) in .net?

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

采纳答案by stevedbrown

WCF in .Net 3.5 is the most similar as long as you aren't trying to use CMP. While it allows service endpoints for SOAP type things, it also allows binary remoting.

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

回答by Cheeso

Definition of terms is important

术语的定义很重要

When doing comparisons, the definition of terms is important. EJB is a component model. It defines persistence, transaction, remoting, activation and security capabilities (and maybe others) for components that operate within the container.

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

You can look at comparable technologies in .NET, if that is what you are after - the technical capabilities of the component model.

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

On the other hand some people use "EJB" as a term to loosely refer to J2EE (or Java EE?). In which case it refers not justto a component model, but to a set of related Java technologies usually associated to server-side applications, including a component model. This might even include toolsets, which of course are only tangentially related to the component model. If thatis the comparison, then it is more aptly described as "J2EE vs. .NET".

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

Still other people might be using an even fuzzier definition for EJB to include things like web services capability, REST/XML communications, or other stuff that is strictly outside Java EE or EJB proper. In other words when they say "compare EJB to .NET" they really mean to compare "Server-side Java platforms to server-side .NET". The latter strikes me as a much more practical comparison to make, than comparing, say, component models.

还有一些人可能对 EJB 使用更模糊的定义，以包含诸如 Web 服务功能、REST/XML 通信或其他严格不属于 Java EE 或 EJB 的内容。换句话说，当他们说“将 EJB 与 .NET 进行比较”时，他们的真正意思是将“服务器端 Java 平台与服务器端 .NET”进行比较。后者让我觉得是一个更实际的比较，而不是比较，比如说，组件模型。

When doing the comparisons, it's important to be clear about just what is being compared.

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

EJB - the component model

EJB - 组件模型

In EJB you define an object and mark it as a Session Bean or an Entity Bean. There's also the late addition of Message Driven Bean. Three flavors of component in EJB. The Session Bean gets activation - how it gets started and possibly "passivated" in times of high resource contention on the server/container. The SB also gets security and remoting services.

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

The basic idea is to define an object and then attach attributes to it, either through the deployment descriptor or through in-code attributes, the analog for which is called annotationsin Java.

基本思想是定义一个对象，然后通过部署描述符或通过代码中的属性将属性附加到它，在 Java 中这种类似的方式称为注解。

The closest thing to a EJB Session Bean is a .NET object. In any .NET application, you can mark an object with transaction attributes, just like a EJB SB. You can make it remotable, if you like, with .NET Remoting and more attributes. Outside of COM+, there is no passivation technology in .NET; .NET just ignores pooling as a generally interesting thing to do with in-memory objects, and as a result there's no approach to do activation/passivation in .NET as there is with EJB.

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

---

---

sidebar #1: that isn't quite true. In .NET, the Workflow capability provides a facility to have long-running activities that can and will be passivated and re-activated. But, Workflow is a distinct metaphor from "server side objects" or "services" which is the centerpoint of most server-side application architectures that use .NET.

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

---

---

sidebar #2: It used to be that the designers of server-side platforms thought everyone was gonna want to use object pooling in order to be more efficient. Now it turns out that the JVM and .NET CLR are fast enough at creating objects, and memory is plentiful enough, that in general, object pooling is not of practical use. It is no longer interesting for the general case, though it still pays good dividends for expensive objects like database connections.

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

---

---

As with EJB, in .NET you can attach security attributes to an object to allow it to run or not run based on the identity of the caller, or other "evidence".

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

Entity Beans are a different animal. While persistence and remoting can be combined, in most practical guidebooks, the recommendation is that an entity bean not expose a remote interface. Instead the recommendation calls for a session bean to call an entity bean. So let's just consider EB's as persistent objects.

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

In .NET there are a bunch of alternatives here. LINQ-to-SQL gives one option - with ORM and persistence services. The ADO.NET Entity Framework is maybe a more comparable technology. Of course all the other services in .NET - transactions security and remoting etc - also can be applied to objects that use ADO.NET Entity Framework or LINQ.

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

On the other hand, depending on where your emphasis is in the EJB umbrella, there may be better comparables. If you primarily use EJB for remoting - and with the advent of REST, SOAP and other lightweight protocols, almost no one does this anymore as far as I can tell - then a better comparable in .NET is WCF.

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

Finally, the comparable to EJB MDB are .NET Queued Components.

最后，可与 EJB MDB 相媲美的是 .NET Queued Components。

EJB Remoting

EJB 远程处理

There are some common aspects to all these types of EJBs - like remote interfaces. Actually most architects recommend that you don't distribute your EJBs. In other words, they discourage people from using the remoting aspect that is so commonly discussed. Instead a servlet should invoke an EJB that is local, rather than invoking one on a remote machine. This is Fowler's First Law: Don't distribute your objects.

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

On the other hand, sometimes you must.
WCF is the communications framework within .NET, and is the aspect in .NET most comparable to EJB remoting. But they are not equivalent. WCF is a very general purpose framework for remote communications, supporting sync and async, multiple protocols, and extensible transport and channel model, while EJB remoting is fairly limited.

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

Is starting from EJB the right approach?

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

EJB doesn't say anything (as far as I know) about web services, or REST, or management or lightweight frameworks, or even HTML, or developer tools. Starting a comparison with "EJB vs blank" artificially constrains the discussion a little bit. It frames the discussion in a way that may not be optimal.

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

There's nothing in EJB to handle, for example, an HTML page metaphor. You get that in servlets or one of its cousins (portlets, etc), some of which are in J2EE proper. But strictly speaking, HTML output isn't covered in EJB.

EJB 中没有任何东西可以处理，例如，HTML 页面隐喻。您可以在 servlet 或其同类（portlet 等）中获得它，其中一些在 J2EE 中是正确的。但严格来说，EJB 不包括 HTML 输出。

Now, maybe you intend one of the more expansive definitions of EJB. To that end, J2EE has now added web services into the specification. But even so, I'm not sure how relevant it is to consider the spec, with the variety of add-on Java-based frameworks for SOAP web services and REST.

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

Likewise, if you want to consider UI capabilities like portlets, servlets, and AJAX and compare them to the .NET equivalents, then you've moved well beyond EJB and J2EE and into server-side Java in general.

同样，如果您想考虑诸如 portlet、servlet 和 AJAX 之类的 UI 功能，并将它们与 .NET 等价物进行比较，那么您已经远远超出了 EJB 和 J2EE，进入了一般的服务器端 Java。

It gets back to my earlier point - be clear and precise in your own mind about what you are interested in examining or comparing.

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

---

---

The EJB and J2EE specifications were ambitious - attempting to define the frameworks for server-side applications. But there was always a time lag between what developers were doing, what the spec was saying, and what the vendors were delivering. You know, maybe there was a 1-year lag between the finalization of a new version of the J2EE spec and the release of a compliant server from IBM.

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

Because of this it ended up being sort of artificial, after-the-fact. The spec was describing things that people were already doing. Things like Spring were coming out and J2EE wasn't saying anything about them. For the longest time J2EE had nothing to say about REST or Web services or AJAX. (Even now, does it say anything about AJAX? I don't know.)

因此，它最终成为一种人为的、事后的。规范描述了人们已经在做的事情。诸如 Spring 之类的东西出现了，而 J2EE 并没有提及它们。在很长一段时间里，J2EE 都没有提及 REST、Web 服务或 AJAX。（即使是现在，它是否说明了 AJAX？我不知道。）

In light of the distance between the theory of the spec and the reality of actual practice by developers, a better approach might be to identify the application requirements, and then compare the appropriateness of EJB and other related technologies to the apps you want to build.

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

In other words - suppose one of your requirements is that the app will be delivered via the browser, and it will have the responsiveness of AJAX. In that case you're going to have to consider jQuery, and that isn't anywhere covered in J2EE, or EJB. AJAX frameworks are available in various products (both Java and .NET). For example Visual Studio uses jQuery for the ASPNET AJAX stuff. But sticking to the specs sort of misses this stuff.

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

Bottom Line

底线

The bottom line is, any app that you build with EJBs can be built in .NET, and vice versa.

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

I think a comparison like "EJB vs .NET" can be interested as an academic discussion, but if you want practical insight into what technology to use where, then you need to think a little differently.

我认为像“EJB 与 .NET”这样的比较作为学术讨论可能会很有趣，但是如果您想实际了解在何处使用什么技术，那么您需要有点不同的想法。

You need to identify and prioritize requirements - like speed of development, cost of deployment, mechanism of deployment, tool support, deployment platform support, language support, performance, UI appearance, UI options, etc. Then weigh the options against that prioritized list.

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

回答by James

One could easily argue Spring.NET...

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

Spring is becoming the norm in the Java side, either in addition to JavaEE/EJB or outright replacing it. Many of the concepts in Spring are very similar to JavaEE/EJB, but simply better. Spring.NET is, obviously, the .NET implementation of it.

除了 JavaEE/EJB 之外，Spring 正在成为 Java 方面的规范，或者完全取代它。Spring 中的许多概念与 JavaEE/EJB 非常相似，但只是更好。Spring.NET 显然是它的 .NET 实现。

Beyond this, I couldn't suggest anything else as I haven't actively used .NET in years...

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

回答by Russ Bradberry

a lot of the EJB functionality is already native in .net (i.e. database transaction) but there is the enterprise services namespace which provides a lot of functionality as well.

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