MVC架构下如何正确绘制UML类图？现有层级关联关系是否正确？

MVC架构类图绘制的正确逻辑 #

你当前给出的层级关联方向是完全反向的，正确的依赖逻辑如下：

• controllers 组合/依赖 services：控制器作为请求入口，需要调用业务逻辑层的能力完成请求处理，会持有service层的实例
• services 组合/依赖 repositories：业务逻辑层需要操作持久化数据，会持有数据访问层的实例
• repositories 组合/依赖 models：数据访问层负责对模型实体做CRUD操作，会引用模型类的结构

UML类图绘制规范 #

1. 分层排布规则
   可以从上到下按调用方到被调用方的顺序排列：Controller层 → Service层 → Repository层 → Model层，View层可以和Controller层并排或者放在Controller层上方，符合常规的调用逻辑认知。
2. 关联关系选择规则

• 如果A类内部持有B类的成员变量，且B的生命周期和A绑定，使用实心菱形+实线箭头的组合关系，箭头从A指向B
• 如果A类仅在方法参数、返回值中用到B类，没有持有B的成员变量，使用虚线箭头的依赖关系，箭头从A指向B
• 不要使用反向的箭头，箭头永远指向被依赖、被调用的一方

3. MVC核心关联补充
   除了三层服务的关联外，还要补充MVC核心三元素的关联：

• Controller关联View：控制器处理完请求后会返回视图或者绑定数据到视图
• View关联Model：视图渲染需要用到模型里的字段数据
• Controller关联Model：控制器会接收请求参数封装成模型，或者从业务层获取模型返回给视图

简单示例（用户管理模块） #

对应的类结构参考：

• UserController：成员变量包含UserService userService，对外暴露getUser()、addUser()等HTTP接口方法
• UserService：成员变量包含UserRepository userRepository，内部实现checkUserValid()、createUserWithDefaultRole()等业务逻辑
• UserRepository：方法入参/返回值用到User类，实现selectById()、insertUser()等数据库操作方法
• User：纯数据模型，仅包含id、username、password等属性和对应的get/set方法，无任何上层类的引用

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