反spring容器开发

       在Spring中，容器注入对象的方法主要有两种，分别是构造函数注入方式与set方法注入方式，其中构造函数方法可以根据参数索引，类型和名称来适配。
例子如下：实体类 Student.java

public class Student {
    private String message;

    public void setMessage(String message) {
        this.message = message;
    }
    public Student(){
        System.out.println("Student对象实例化");
    }
    public Student(String name){
        System.out.println("Student对象实例化   name="+name);
    }
    public Student(int i,String name){
        System.out.println("Student对象实例化");
        System.out.println("i="+i+"   name="+name);
    }
    public void printmessage(){
        System.out.println(message);
    }

}

构造函数注入方式：

<!-- 配置要管理的bean 无参构造 -->
        <bean name="stun" id="stu" class="com.java.demo.Student"></bean>
        <!-- 配置一个根据参数值创建bean实例的方式jedis 会用到 -->
        <bean name="stu1" class="com.java.demo.Student">
            <!-- 通过构造函数的类型，名称，索引来适配 -->
            <!-- 通过索引来智能匹配 -->
            <constructor-arg index="0"  value="10"></constructor-arg>
            <constructor-arg index="1"  value="10"></constructor-arg>
        </bean>
        <bean name="stu2" class="com.java.demo.Student">
            
            <!-- 通过类型来智能匹配 -->
            <constructor-arg type="int"  value="12"></constructor-arg>
            <constructor-arg type="String" value="12"></constructor-arg>
        </bean>
        <bean name="stu3" class="com.java.demo.Student">
            
            <!-- 通过名称来智能匹配 -->
            <constructor-arg name="i"  value="13"></constructor-arg>
            <constructor-arg name="name" value="13"></constructor-arg>
        </bean>

通过set方法来注入：对message属性进行赋值 即依靠属性方法来注入

<bean name="stu4" class="com.java.demo.Student">
    <property name="message" value="初始的信息"></property>
</bean>
相信上面的两种方式，不管是xml方式，还是java 文件的配置方式，作为开发的大家已经非常熟悉了。大家日复一日，年复一年的使用这种方法。但是很少有人对这种方式提出质疑，因为在MVC模式的开发中，从controller,service,dao层大家都是这样去用@contrlloer,@service,@resposity配置controller,service,dao。业务逻辑全部堆积在service层，如果对于大型复杂系统来说，这无疑致命的。在service层的方法代码里，有着上万行的代码，各种if esle,各种工具类，各种方法调用方法。对于新增新的需求或者对原有业务逻辑的改造，动一个方法的逻辑，可能造成各种新的bug。为什么会这样，为什么会这样？大家有想过吗？归咎原因，是因为一行代码承担了太多的职责。为了满足一个职责，做的改动，影响了其他职责。就spring容器有解决方案吗？请关注后面文章