.NET – vs EJB
在.net中EJB（Enterprise Java Bean）的可比技术是什么？
只要您不尝试使用CMP，.Net 3.5中的WCF就是最相似的。 虽然它允许服务端点用于SOAP类型的东西，但它也允许二进制远程处理。
术语的定义很重要
在进行比较时，术语的定义很重要。 EJB是一个组件模型。 它为容器内运行的组件定义持久性，事务，远程处理，激活和安全function（以及其他function）。
您可以在.NET中查看可比较的技术，如果这是您所追求的 – 组件模型的技术function。
另一方面，有些人使用“EJB”作为松散地引用J2EE（或Java EE？）的术语。 在这种情况下，它不仅指代组件模型，还指通常与服务器端应用程序相关联的一组相关Java技术，包括组件模型。 这甚至可能包括工具集，当然这些工具集只与组件模型相关。 如果这是比较，那么它更恰当地描述为“J2EE vs. .NET”。
还有一些人可能会使用更为模糊的EJB定义来包含Web服务function，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中，工作流function提供了一种工具，可以进行长时间运行的活动，这些活动可以并且将被钝化和重新激活。 但是，Workflow是一个与“服务器端对象”或“服务”不同的隐喻，它是使用.NET的大多数服务器端应用程序体系结构的中心点。
侧栏＃2：曾经是服务器端平台的设计者认为每个人都想要使用对象池以提高效率。 现在事实certificate，JVM和.NET CLR在创建对象方面足够快，并且内存足够丰富，通常，对象池没有实际用途。 它对于一般情况不再有意思，尽管它仍然为像数据库连接等昂贵的对象带来了好处。
与EJB一样，在.NET中，您可以将安全属性附加到对象，以允许它根据调用者的身份或其他“证据”运行或不运行。
实体豆是一种不同的动物。 虽然可以组合持久性和远程处理，但在大多数实用指南中，建议实体bean不公开远程接口。 相反，该建议要求会话bean调用实体bean。 因此，让我们将EB视为持久对象。
在.NET中，这里有很多替代方案。 LINQ-to-SQL提供了一个选项 – 使用ORM和持久性服务。 ADO.NETentity framework可能是一种更具可比性的技术。 当然，.NET中的所有其他服务 – 事务安全性和远程处理等 – 也可以应用于使用ADO.NETentity framework或LINQ的对象。
另一方面，根据您在EJB中的重点，可能会有更好的可比性。 如果您主要使用EJB进行远程处理 – 并且随着REST，SOAP和其他轻量级协议的出现，据我所知，几乎没有人会这样做 – 那么在.NET中更好的可比性是WCF。
最后，与EJB MDB相当的是.NET Queued Components。
EJB Remoting
所有这些类型的EJB都有一些共同的方面 – 比如远程接口。 实际上，大多数架构师建议您不要分发EJB。 换句话说，他们不鼓励人们使用如此常见的远程方面。 相反，servlet应该调用本地的EJB，而不是在远程机器上调用它。 这是福勒的第一定律 ： 不要分发你的物品 。
另一方面，有时你必须。
WCF是.NET中的通信框架，是.NET中与EJB远程处理最相似的方面。 但它们并不等同。 WCF是一个非常通用的远程通信框架，支持同步和异步，多协议，可扩展传输和通道模型，而EJB远程处理相当有限。
从EJB开始是正确的方法吗？
关于Web服务，REST，管理或轻量级框架，甚至HTML或开发人员工具，EJB都没有说（据我所知）。 开始与“EJB vs blank ”进行比较，人为地限制了讨论。 它以可能不是最佳的方式构成讨论的框架。
EJB中没有任何东西可以处理，例如，HTML页面隐喻。 你可以在servlet或其中一个表兄弟（portlet等）中获得它，其中一些是在J2EE中。 但严格来说，EJB中没有涉及HTML输出。
现在，也许你想要一个更广泛的EJB定义。 为此，J2EE现在已将Web服务添加到规范中。 但即使这样，我也不确定考虑规范的相关性，以及用于SOAP Web服务和REST的各种基于Java的附加框架。
同样，如果你想要考虑像portlet，servlet和AJAX这样的UIfunction，并将它们与.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 vs .NET”之类的比较可以作为一个学术讨论感兴趣，但如果你想要实际洞察使用哪种技术，那么你需要有所不同。
您需要确定需求并确定其优先级 – 例如开发速度，部署成本，部署机制，工具支持，部署平台支持，语言支持，性能，UI外观，UI选项等。然后根据优先级列表权衡选项。
人们可以很容易地争论Spring.NET ……
除了JavaEE / EJB或者直接替换它之外，Spring正在成为Java方面的常态。 Spring中的许多概念与JavaEE / EJB非常相似，但更好。 Spring.NET显然是它的.NET实现。
除此之外，我无法提出任何其他建议，因为我多年没有积极使用.NET了……
很多EJBfunction已经在.net中存在（即数据库事务），但是企业服务命名空间也提供了很多function。