相关疑难解决方法(0)

首先,我要澄清一下,这篇文章并不是要批评CDI,而是要发现CDI设计背后的思路和假设,这对设计任何使用CDI的网络应用程序都有明显的影响.

CDI(Java EE 6)最显着的特征之一是类型安全.Jboss Seam在类型上并不安全.它使用name来限定要注入的任何实例.如下:

   @Name("myBean")
   public class MyBean implements Bean {
     ...
   }

   @Name("yourBean")
   public class YourBean implements Bean {
     ...
   }

注入MyBean时,可以这样做:

   @In
   private Bean myBean; //myBean is injected

   @In
   private Bean yourBean; //yourBean is injected  

早期版本的Spring(3.0之前),这种类型的注入发生在下面:

只需在bean配置文件中定义bean:

   <bean id="myBean" class="com.example.common.MyBean">
       ...
   </bean>

   <bean id="yourBean" class="com.example.common.YourBean">
       ...
   </bean>

并使用命名限定符,决定使用哪一个:

   @Autowired
   @Qualifier("myBean")
   private Bean bean;

   @Autowired
   @Qualifier("yourBean")
   private Bean bean; 

但现在在CDI中,首先需要Qualifier为任何特定类型的对象定义自定义注释.然后使用该注释来限定该对象.在一天结束时,当您查看源代码时,您会发现,您浪费了大量时间为依赖注入编写大量自定义注释.Java社区正朝着注释方向发展,将基于XML的配置(冗长的XML)留在后面.有没有什么可以说服任何人认为这(使用自定义注释键入安全性)不是冗长的注释,而是作为CDI的优秀和杰出特征？

编辑:

积分,推动突出显示

1. 如果我使用自定义限定符来实现每个服务的类型安全性或dao(每个接口),那么对于大型应用程序(如具有1000个或更多服务或具有多个实现的dao类),它将是混乱的.那么对于大型应用,使用类型安全注入是否可行？
2. 如果上述问题的答案为"否",那么使用类型安全有什么意义呢？
3. 即使为类型安全编写注释是可行的,但在大型应用程序中,仅仅为了避免冗长的xml配置真的值得付出努力吗？
4. 实际上我需要类型安全而不是bean名称限定符？

关于以上几点的简短讨论

1. 当你真正需要类型安全注入时,没有太多的情况,特别是当你有一个接口的实现时,你应该 …