分层架构中各对象的作用

前言

​ ​ 在 MVC（Model-View-Controller）分层架构模式中，不同类型的对象承担着不同的职责和作用。下面是对常见的几种对象类型及其在分层架构中的作用的详细解释：

1、DO（Domain Object 或 Data Object）

• 作用：DO通常用于表示业务领域内的实体，并直接映射到数据库表。它们封装了数据以及与该数据相关的业务逻辑。
• 使用场景：主要用于持久化层（DAO或Repository），也可以在服务层中被用来处理业务逻辑。
• 位置：一般位于 entity 或 domain 包内。
• 示例：

@Entity
public class UserDO {
    @Id
    private Long id;
    private String username;
    private String password;
    // getter and setter methods...
}

2、DTO（Data Transfer Object）

• 作用：DTO用于在不同系统或应用层之间传输数据。它可以帮助减少远程调用次数，并且可以控制暴露给外部的数据量。
• 使用场景：当需要将数据从服务层传递给控制器层或者前端时使用；也可用于服务间通信。
• 位置：通常位于 dto 包内。
• 示例：

public class UserDTO {
    private Long id;
    private String username;
    // 不包含敏感信息如password
    // getter and setter methods...
}

3、DAO（Data Access Object）

• 作用：提供对数据库或其他持久化存储的抽象接口。DAO隐藏了所有底层数据库操作细节，允许上层通过简单的接口访问数据。
• 使用场景：用于执行数据库操作，如查询、插入、更新等。
• 位置：一般位于 dao 或 repository 包内。
• 示例：

public interface UserDao {
    UserDO findById(Long id);
    void save(UserDO user);
}

4、VO（View Object 或 Value Object）

• 作用：VO主要用于展示层，表示特定视图所需的数据模型。它可以是来自一个或多个DO的数据组合，根据UI需求定制。
• 使用场景：当需要将数据传递给前端展示时使用。
• 位置：通常位于 vo 包内。
• 示例：

public class UserVO {
    private Long id;
    private String displayName; // 可能是从username转换而来
    // 其他专门为前端准备的信息
    // getter and setter methods...
}

5、BO（Business Object）

• 作用：BO封装了业务逻辑，可以看作是业务规则的具体实现。它可能包含多个DO对象，并负责协调这些对象之间的交互以完成复杂的业务流程。
• 使用场景：当存在复杂业务逻辑需要独立于具体的服务实现时使用，说白了就是为了增加代码的复用性和简化Service层的设计。
• 位置：一般位于 bo 或 business 包内。
• 示例：

public class OrderBO {
    private OrderDao orderDao;
    private InventoryDao inventoryDao;

    public void placeOrder(OrderDO order) throws Exception {
        if (inventoryDao.checkStock(order.getProductID(), order.getQuantity())) {
            orderDao.save(order);
            inventoryDao.updateStock(order.getProductID(), order.getQuantity());
        } else {
            throw new InsufficientStockException("Not enough stock available");
        }
    }
}

备注：

​ ​ 在实际项目中，是否区分BO和服务层取决于项目的规模和复杂度。对于较小的项目，服务层可以直接包含业务逻辑，无需单独定义BO。而对于大型企业级应用，将业务逻辑从服务层中抽离到BO中可以使系统更加模块化，易于维护和扩展。

​ ​ 例如，在一个电子商务系统中，OrderService类可能会调用 OrderBO来处理订单创建过程中的所有业务规则（如折扣计算、库存检查等），然后通过 OrderDAO保存订单信息。这样做的好处是可以清晰地分离出业务逻辑和技术实现细节，便于管理和扩展。