Java MVC模式实践：餐厅管理系统代码结构与职责分离优化-java教程-PHP中文网

Java MVC模式实践：餐厅管理系统代码结构与职责分离优化

本文深入探讨了java中mvc（model-view-controller）模式在餐厅管理系统中的应用与优化。通过分析现有代码结构，我们识别了视图层中存在的业务逻辑混合问题，并阐述了将这些决策逻辑迁移至控制器层的必要性。文章强调了模型、视图、控制器职责分离的重要性，提供了代码重构建议，并讨论了异常处理在mvc各层中的恰当位置，旨在提升代码的可维护性、可测试性和扩展性。

1. 理解MVC模式核心原则

MVC（Model-View-Controller）是一种经典的设计模式，旨在将应用程序的业务逻辑、数据和用户界面分离开来。其核心思想是将应用程序划分为三个相互关联的组件，每个组件负责特定的职责：

模型（Model）: 负责管理应用程序的数据和业务逻辑。它不直接与用户界面交互，只提供数据和操作数据的方法。模型应该能够独立于视图和控制器进行测试。在餐厅管理系统中，DailyMenu、MenuItem、Menu、FoodMenu、DrinkMenu、Bill等类及其相关的业务服务（如DailyMenuServicesImpl）构成了模型层。
视图（View）: 负责数据的可视化展示和用户交互。它从模型获取数据并呈现给用户，同时捕获用户输入并将其传递给控制器。视图不包含任何业务逻辑，其职责仅限于显示和接收输入。在命令行界面（CLI）应用中，视图负责打印提示信息和读取用户输入。
控制器（Controller）: 接收并处理用户的输入，协调模型和视图之间的交互。它根据用户输入调用模型的业务逻辑来更新数据，然后选择合适的视图来显示更新后的数据。控制器是模型和视图之间的桥梁，负责决策和调度。

2. 初始代码结构分析与MVC职责偏差

在分析初始的餐厅管理系统代码时，我们发现了一些MVC职责分离不明确的问题，尤其是在视图层：

2.1 模型层的良好实践

DailyMenu等数据模型类清晰地定义了数据结构，DailyMenuServicesImpl提供了CRUD操作，这些都符合模型层的职责，即专注于数据管理和业务逻辑。

public class DailyMenu implements Serializable {
    private List<MenuItem> menuItemList;
    // ... getter and setter ...
}

登录后复制

2.2 视图层（MenuView）的职责混淆

初始的MenuView中，存在将用户输入解析后的“决策逻辑”与显示逻辑混合的问题。例如，getMenuTypes、getFoodMenuTypes和getDrinkMenuTypes方法不仅负责显示菜单选项和获取用户输入，还包含了根据用户选择来决定返回哪个具体菜单对象的switch语句。

立即学习“Java免费学习笔记（深入）”；

// 初始MenuView中的问题示例
public DailyMenu getMenuTypes(Menu menu){;
    menu(); // 显示菜单
    int option = Integer.parseInt(scanner.nextLine()); // 获取输入
    MenuTypes menuTypes = MenuTypes.get(option-1);
    switch (menuTypes){ // 决策逻辑
        case FOODMENU -> {return getFoodMenuTypes(menu.getFoodMenu());}
        case DRINKMENU -> {return getDrinkMenuTypes(menu.getDrinkMenu());}
        default -> {return null;}
    }
}

登录后复制

这种模式的缺点在于：

业务逻辑内嵌: switch语句是根据用户选择进行业务判断和数据流控制的逻辑，这属于控制器而非视图的职责。
难以维护和测试: 如果未来需要更换用户界面（例如从CLI切换到GUI），视图层将需要大量修改，因为其中包含了与UI无关的业务决策。
违反单一职责原则: MenuView不仅负责显示，还负责部分业务决策。

2.3 主方法（Main）作为控制器与视图的混合体

在初始设计中，Main方法承担了大部分的控制逻辑，直接调用视图方法获取输入，然后调用服务方法进行业务处理。虽然它充当了控制器，但其内部也包含了直接的UI输出（如System.out.println）和对视图的直接操作，使得控制器与视图的边界不够清晰。

3. 优化后的代码结构分析与MVC职责分离

在后续的“Edit”部分，代码进行了显著的改进，引入了专门的控制器类，并进一步分离了视图和控制器的职责。

3.1 引入专用控制器（MenuControllers）

通过引入MenuControllers类，应用程序的控制逻辑得到了集中管理。现在，Main方法只需调用MenuControllers的方法来处理用户操作，而MenuControllers则负责协调MenuView和DailyMenuServices。

// 优化后的Main方法
public static void menuMain(Menu menu) throws IOException{
    // ...
    MenuControllers menuControllers =  new MenuControllers(); // 实例化控制器
    // ...
    switch (actions) {
        case CREATE -> menuControllers.add(menu); // 调用控制器方法
        // ...
    }
}

登录后复制

3.2 视图层（MenuView）的职责回归

优化后的MenuView变得更加纯粹，它只负责显示信息和获取用户输入，不再包含根据用户选择进行业务决策的switch逻辑。例如，getMenuTypes()现在只返回用户选择的整数选项，而不直接进行业务判断。

乾坤圈新媒体矩阵管家

新媒体账号、门店矩阵智能管理系统

查看详情

// 优化后的MenuView
public class MenuView {
    private Scanner scanner = new Scanner(System.in);
    // ...
    public int getMenuTypes(){ // 只负责获取输入
        menu();
        return Integer.parseInt(scanner.nextLine());
    }
    // ...
    public void printMenu(Menu menu){ // 只负责显示
        menuPrinter.printMenu(menu);
    }
}

登录后复制

MenuView中将MenuPrinter的调用封装在printMenu方法中，进一步将打印逻辑从控制器中解耦，使得控制器不必关心如何“打印”菜单，只需调用view.printMenu(menu)即可。

3.3 控制器（MenuControllers）承担决策逻辑

现在，MenuControllers承担了根据用户输入进行业务决策的职责。例如，add方法会从MenuView获取用户选择的菜单类型，然后使用switch语句来决定调用哪个具体的服务方法来添加菜单项。

// 优化后的MenuControllers
public class MenuControllers {
    // ...
    public void add(Menu menu){
        MenuItem  menuItem = view.createMenuItem();
        int option = view.getMenuTypes(); // 获取用户选择
        MenuTypes menuTypes = MenuTypes.get(option-1);
        switch (menuTypes){ // 决策逻辑在控制器中
            case FOODMENU -> addToFoodMenu(menu.getFoodMenu(),menuItem);
            case DRINKMENU -> addToDrinkMenu(menu.getDrinkMenu(),menuItem);
        }
    }
    // ...
}

登录后复制

这种分离是MVC模式的关键，它确保了：

清晰的职责: 每个组件都专注于其核心职责。
更高的可测试性: 控制器可以独立于视图进行测试。
更好的可维护性: 更改UI不会影响控制器和模型，反之亦然。

3.4 模型层（DailyMenuServicesImpl）的改进

优化后的DailyMenuServicesImpl在updateMenu方法中移除了menuPrinter.printMenu(dailyMenu)的调用，确保了服务层只关注业务逻辑和数据操作，不涉及任何视图渲染。同时，它引入了更健壮的错误处理机制，当找不到指定菜单项时抛出NullPointerException。

// 优化后的DailyMenuServicesImpl
@Override
public void updateMenu(DailyMenu dailyMenu,MenuItem updateMenuItem,String itemName) {
    dailyMenu.getMenuItemList().stream()
                                .filter(menuItem -> menuItem.getNames().equals(itemName))
                                .findFirst()
                                .ifPresentOrElse(menuItem -> {
                                    // ... update logic ...
                                },()->{
                                    throw new NullPointerException("Wrong menu Item name !!!"); // 业务逻辑异常
                                });
}

登录后复制

4. 异常处理策略

关于异常处理，其在MVC不同层级中的处理方式应遵循各自的职责：

视图层（View）: 主要负责处理用户输入相关的格式错误（如NumberFormatException当用户输入非数字字符时）。视图层可以捕获这些异常，并向用户显示友好的错误提示，要求重新输入。视图层不应处理业务逻辑异常。

// 示例：MenuView中处理输入格式异常
public int getMenuTypes(){
    menu();
    try {
        return Integer.parseInt(scanner.nextLine());
    } catch (NumberFormatException e) {
        System.out.println("无效输入，请输入数字选项。");
        return -1; // 或者抛出自定义异常，由控制器处理
    }
}

登录后复制

控制器层（Controller）: 负责捕获来自模型/服务层的业务逻辑异常（如NullPointerException表示“找不到菜单项”）。控制器根据这些异常决定如何响应用户，例如向视图发送错误消息，或者重新加载某个视图。控制器也可能捕获视图层抛出的输入验证异常，并决定是否重试或提示用户。

// 示例：MenuControllers中处理业务逻辑异常
public void update(Menu menu){
    try {
        view.printMenu(menu);
        String foodName = view.getMenuItemName();
        MenuItem  menuItem = view.createMenuItem();
        int option = view.getMenuTypes();
        // ... (根据option调用addToFoodMenu/addToDrinkMenu)
    } catch (NullPointerException e) { // 捕获服务层抛出的业务逻辑异常
        System.out.println("操作失败: " + e.getMessage());
    } catch (NumberFormatException e) { // 捕获视图层输入格式异常
        System.out.println("输入格式错误，请检查您的输入。");
    }
}

登录后复制

模型/服务层（Model/Service）: 专注于业务逻辑的实现，当业务规则被违反或数据操作失败时，应抛出描述性的异常。这些异常可以是Java内置异常（如IllegalArgumentException、NullPointerException），也可以是自定义的业务异常。服务层不应处理用户界面或控制流相关的异常。

在当前的Main方法中，统一捕获了多种异常。对于一个简单的CLI应用，这可以作为顶层的错误处理机制。但在更复杂的系统中，建议将异常处理下沉到更具体的控制器方法中，以便进行更精细的错误处理和用户反馈。