Java EJB3业务代表

使用EJB3时是否有任何理由进行委托？因为我从委托中看到的唯一真正好处是它允许隐藏EJB体系结构的查找和访问细节。嗯，它也提供了一些解耦功能，但它大部分是未使用的。对于EJB3，我们有注入，所以现在我可以创建一个带有@EJB注释的变量，并按原样使用它。 我还需要代表吗？这是注射资源消耗吗？我的意思是，如果我在JSF的请求管理bean中使用它，那么还是使用委托来减少这些注入调用更好

谢谢大家!

让我们回顾一下原作的力量：

• 表示层客户端需要访问业务服务
• 不同的客户端（如设备、Web客户端和厚客户端）需要访问业务服务
• 业务服务API可能会随着业务需求的发展而变化
• 希望尽量减少表示层客户端和业务服务之间的耦合，从而隐藏服务的底层实现细节，例如查找和访问
• 客户端可能需要实现业务服务信息的缓存机制
• 减少客户机和业务服务之间的网络流量是可取的

所有这些力量在今天仍然是相关的——它们不是每个项目中都必须存在的，但可能存在

主要的变化是我们不需要业务委托来最小化耦合（斜体）。依赖注入解决了查找和访问问题

我喜欢：关于耦合的一点，仍然没有自然解决的是例外。异常现在已取消选中，但仍然存在。客户机是否应该完全屏蔽EJB异常再次取决于项目中存在的力

在引入业务委托模式来解决查找和访问问题的情况下（我怀疑很多项目都是这样），我们实际上不再需要它了。如果业务委托是出于其他原因，它仍然有意义

---

PS：根据我自己的经验，资源注入从来都不是一个性能问题（我总是在其他地方遇到比注入毫秒更严重的性能问题：）

业务代理只是一个用JNDI查找和所有相关清理和错误捕获来隐藏整个混乱的黑客。资源注入是通过Gavin Kings Seam进入J2EE的，它基本上遵循尽可能少的层和所有配置在一个地方的原则。所以，忘掉那些旧模式，只需使用普通的OO思考

---

我的2美分。

嗯，实际上我不太明白这些要点

表示层客户端需要访问 商业服务

JSF中的表示层是托管bean，不是吗？如果是这样的话，这个问题就通过注入解决了。对吧?

不同的客户端，例如设备， Web客户端和厚客户端需要 获得商业服务

我没有设备和厚客户端。什么是web客户端？从上面看，它不是同一个表示层吗？如果是这样的话，我们的情况和上面一样

业务服务API可能会随着时间的推移而变化 业务需求不断变化

我不明白当API发生变化时，代理实际上是如何提供帮助的。当然，如果只是一些小的更改，您可以通过更改一些传递参数的类型来处理，或者只使用某个字段而不是某个参数来处理，那么这会有所帮助，但我认为这种情况不会经常发生，而且从托管bean或其他方面更改方法调用也不是那么困难，甚至可能更好。而主要的更改将要求更改方法调用

客户端可能需要实现缓存 商业服务机制 信息

缓存是一个困难的问题，因为我不知道缓存什么以及如何做：）这是否意味着我可以创建一些变量来存储一些结果，并且仅在第一次调用这个变量时才使用ejb调用？作为一名代表，这种共享资源的做法是否良好

希望减少网络开销 客户端和业务之间的通信量 服务

---

代理如何减少网络流量？使用存储某些值的变量的相同方法

您似乎混淆了“服务定位器”和“业务委托”——正如下面的答案所示，业务委托的原因与抽象所有JNDI使用和隐藏初始上下文创建、EJB主对象查找等的复杂性不同