Java餐厅管理作业是否符合MVC模式？异常处理应置于何处？

问题背景 #

我正在开发遵循MVC模式的餐厅管理课程作业，相关设计与架构调整如下：

• 模型设计：Menu体系分为食品菜单（含早餐、午餐、晚餐）和饮品菜单（含酒精饮料、软饮），通过父类DailyMenu封装通用CRUD操作逻辑，子类继承实现代码复用。
• 架构演进：最初代码中MenuView直接依赖Service，Main方法也直接调用View和Service；后续新增MenuControllers作为中间层，调整MenuView仅负责视图交互，Service采用单例模式实现业务逻辑。

现咨询两个问题：

1. 修改后的结构是否符合MVC模式规范？
2. 异常处理应放置在MVC的View层还是Controller层？

问题解答 #

1. 修改后的结构符合MVC规范 #

MVC核心是分层解耦，各层职责明确：

• Model层：DailyMenu父类及各类菜单子类，负责封装数据实体与通用业务逻辑（CRUD复用），完全符合Model层处理数据与核心业务规则的职责。
• View层：调整后的MenuView仅负责视图交互（比如展示菜单列表、接收用户操作输入），不再直接依赖Service，只专注于界面展示与用户输入收集，符合View层的定位。
• Controller层：新增的MenuControllers作为中间调度者，接收View传递的用户请求，调用Service处理业务逻辑，再将处理结果反馈给View更新界面，完美承担了Controller层解耦View与Service、协调各层交互的核心职责。

这种分层完全满足MVC的设计原则，实现了各层职责单一、低耦合高内聚的要求。

2. 异常处理的分层策略 #

• Controller层是异常处理的核心层：
  Controller作为View与Service的中间枢纽，应该捕获Service层抛出的业务异常（比如菜单不存在、操作非法等），将异常转换为用户可理解的友好提示信息，再传递给View展示。同时，Controller也可以处理一些请求参数校验的异常，确保不符合要求的请求不会流入Service层。
• View层仅负责展示异常信息：
  View层不需要处理异常逻辑，只需要接收Controller传递过来的提示内容，以合适的方式（比如弹窗、文本提示）展示给用户即可。避免在View层中编写try-catch处理业务相关异常，防止View层混入业务逻辑，破坏分层原则。
• 补充建议：Service层应抛出特定的业务自定义异常（如MenuNotFoundException、InvalidMenuOperationException），而非通用的Exception，这样Controller可以更精准地识别异常类型，返回对应的个性化提示。

内容的提问来源于stack exchange，提问作者David Moore