SSM框架学习DI入门——day2

在业务层中删除使用的new方式创建Dao对象

复制代码

public class BoolServiceImpl implements BookService{
    private BookDao bookDao;
    public void save(){
        System.out.println("book service save...")
        bookDao.save();
    }
    //提供对应的set方法
    public void setBookDao(BookDao bookDao){
        this.bookDao = bookDao;
    }
}

1.在配置文件中导入spring坐标spring-context

2.配置bean标签id属性标示给bean的名字、class属性给bean的定义类型

<bean id="bookDao" calss="com.itheima.dao.impl.BookDaoImpl"/>

3.配置service和dao的关系、property标签表示配置当前bean属性、name为配置哪一个具体属性，ref表示参照哪一个bean

<bean id="bookService" calss="com.itheima.dao.impl.BookServiceImpl"

<property name="bookDao" ref="bookDao"/>

</bean>

两个名称相同但是不是一个东西，name="bookDao"属性的名称，ref="bookDao"当前容器对应的bean的名称。Set方法是容器中在执行

Service 和 Dao 的关系

在分层架构的应用程序中，Service 层和 Dao 层是常见的两个层级，它们各自承担不同的职责，并通过协作完成业务逻辑和数据访问。

职责划分

Dao 层（Data Access Object）

Dao 层的主要职责是与数据库直接交互，负责数据的增删改查（CRUD）操作。它封装了数据库访问细节，提供简单的接口供上层调用。Dao 层不包含业务逻辑，仅关注数据的持久化。

Service 层

Service 层负责处理业务逻辑，协调多个 Dao 操作或其他 Service 调用，完成复杂的业务需求。Service 层通常包含事务管理、权限校验、数据校验等逻辑，是业务逻辑的核心实现层。

协作方式

Service 层通过调用 Dao 层的方法来访问数据库，但不会直接处理数据库底层细节。例如，一个用户注册的 Service 方法可能会调用 UserDao 的插入方法，同时调用其他 Dao 完成关联操作（如记录日志、初始化用户配置等）。

Dao 层作为数据访问的底层组件，通常被设计为无状态的工具类，而 Service 层则可能包含更多的业务状态和流程控制。

代码示例

以下是一个简单的 Java 示例，展示 Service 和 Dao 的协作：

java 复制代码

// Dao 层示例
public interface UserDao {
    void save(User user);
    User findById(Long id);
}
// Service 层示例
@Service
public class UserService {
    @Autowired
    private UserDao userDao;

    public void registerUser(User user) {
        // 业务逻辑校验
        if (user == null || user.getName() == null) {
            throw new IllegalArgumentException("Invalid user data");
        }
        // 调用 Dao 完成持久化
        userDao.save(user);
    }
}

设计原则

单一职责原则

Dao 只负责数据访问，Service 只负责业务逻辑，避免功能混杂。

依赖倒置原则

Service 依赖 Dao 的抽象接口（如 UserDao），而非具体实现，便于测试和扩展。

事务边界

事务通常由 Service 层控制，确保多个 Dao 操作在同一个事务中执行。

Bean的基础配置：

在bean中，没定义的bean错误，可能是xml写错，或是java文件写错

spring创建的bean默认是单例对象，添加scope prototype

Bean默认单例的原因

Spring框架中Bean默认采用单例模式（Singleton）的设计，主要基于性能、资源管理和设计合理性的考量。以下是具体原因：

性能优化

单例模式减少了对象的频繁创建和销毁。每次请求都创建新实例会消耗额外的内存和CPU资源，尤其在并发量高时，频繁的GC（垃圾回收）可能导致性能瓶颈。单例模式通过复用实例降低了系统开销。

资源共享

许多Bean是无状态的（如Service、DAO层组件），它们不存储用户特定的数据，因此可以被多个线程共享。单例模式确保所有请求共用同一实例，避免重复初始化依赖项或加载配置资源。