项目背景

应用场景：项目是软工大作业要求做一个桌面应用。当时开发时直接奔着需求就开写了，没有统一好设计，于是乎组内几个同学写的代码八仙过海各显神通，高度耦合且不说，相互之间阅读起来非常费劲，每次有谁遇到一个bug其他几人得先花好久学习他的代码逻辑。于是在第一轮迭代的过程中我自己整理了一套框架，或者说规范，来改善团队的开发效率。本篇主要用于记录和介绍框架的设计思路和使用方法。

一点野史：我设计这套规范的初衷主要是为了统一组内页面跳转和数据交互的代码风格，最开始就只是封装了utils里的几个工具类。结果写完盯着目录和javafx文档感觉文思泉涌，第二天花了一天奔着解耦为目的把代码结构重构了一遍，发现效果不错，信心爆棚，于是厚颜无耻的跟组员说我想出了一套“框架”。

设计思路

MVVM

首先开门见山，这套规范的骨架采用了MVVM的思想，简单来说就是在传统MVC的基础上，解耦了VC里的部分业务，形成了一个专门为View层处理与后台进行数据交互业务的View-Model层，并通过绑定把数据动态更新到View层。本项目使用javafx提供的property属性，实现了VM和V层的双向绑定，使交互得到的最新数据自动展示到了V层。虽然会多写一个层多一点代码，但这种结构就很清爽，对于团队开发，以及我这种轻度代码洁癖患者可以说是非常友好了。

使用VM层来管理数据交互的另一个好处是减少同一份数据在多个页面来回的传输。举个例子，我想要我的APP每一个页面右上角都出现用户的头像，姓名，年龄...一组信息。以前MVC的解决思路是在每次跳转到新页面时1.重新从后台请求一次用户信息2.从上一个页面把信息传过来，或是使用session/cookie；MVVM中由于V层和VM层之间通过绑定来同步数据，那么同一个VM类维护的数据可以同步到多个V层页面，省去了每个页面中相同的传数据的代码。

注：在这个项目中，我对VM层的理解是：一个VM实现类负责一组抽象的业务（如维护一套用户信息），它不一定要和后端Entity一对一，也不一定和页面一对一，而是根据具体业务情况实现单例复用。

在本项目的设计中，如果进一步来看，三层里面各自又可以分为若干层

从右向左看：

Model层

Model层只负责数据持久化，内部结构同MVC

本项目由于老师要求不联网，因此就免去了controller层和service层（紫色部分），ViewModel层直接调用DAO层获取数据（绿色笔画的部分标识具体代码中的调用关系。）

ViewModel层

小ViewModel层（里面那个）只负责前端事件的数据处理，并和Model层进行数据同步。DTO层是对前端使用数据的一套封装类，如后台中User的个人信息和User的购课数量在两个不同的entity类里，那么在ViewModel实现类（里面那个）就可以把二者封装到一个UserDTO类里。

View层

View层负责展示页面，页面跳转和监听用户操作事件，不管数据处理。其内部的controller不是MVC里的controller（但是javafx喜欢叫他controller所以我就沿用了），它负责一个fxml页面/组件的前端逻辑，controller和fxml的关系是一对一。其实硬要说的话，View红框里的controller层对应MVP里的presenter，fxml层对应MVP的view。controller层负责处理前端页面逻辑以及和VM之间的通信，fxml（真正的view层）就变成了薄薄的一层纯xml页面样式。从这个角度来看，这个项目的框架实际上是结合了MVP和MVVM的思想，形成了一个M-VM-P-V的结构。

静态代理

javafx提供的FXMLLoader类加载controller和fxml文件的代码有很多种不同的写法，由于历史原因，有些写法貌似不兼容项目使用的openfx最新版sdk（16），为了统一组内的写法，我写了一个封装了FXMLLoader一些基本应用的静态代理工具类。

好吧，这么写qs有点多此一举，其实是我每次加载页面都要写好几行代码，看着难受，干脆封装起来一行搞定。（当然后续有精力搞什么AOP也是可以用的）

中介者模式

中介者集中管理一组需要相互调用的controller类。加载fxml的时候把controller注册进中介者，然后谁要用这个controller（从另一个页面/组件调用这一个页面/组件的前端业务）就直接去中介者里面拿，然后调用就好。

写不动了，以后慢慢写

单例工厂

项目中已实现的工厂是上述中介者的单例工厂。后续有需要还可以加VM的工厂。

目录结构