四赤阳阵是一种结界忍术，比“四紫炎阵”强上数十倍，必须要四位影级人物同时发动。
视图和四赤阳阵非常像，一般视图由多个表组成一个整体进行展示。
数据库View的概念
- 传统DB视图，主要用于多表内容聚合展示，不支持直接基于视图进行新增和修改。
- 视图的主要作用是聚合查询，并不是为了自动关联修改。
需求的合理性
- 1V1关联表，可以直接操作
- 1VN or NVN 关联，仅提供查询，不应该提供编辑功能
即使隔着屏幕，我仿佛也能感受到你们有些茫然的样子
但是，相信看完这以下介绍您就会理解。
什么是1V1关联表？
SELECT
`users`.`id` AS `id`,
`users`.`status` AS `status`,
`users`.`login_id` AS `login_id`,
`users`.`login_pwd` AS `login_pwd`,
`users`.`nickname` AS `nickname`,
`users`.`reg_time` AS `reg_time`,
`users`.`info` AS `info`,
`users_exp`.`users_id` AS `users_id`,
`users_exp`.`exp` AS `exp`,
`users_exp`.`avg` AS `avg`,
`users_exp`.`qq` AS `qq`
FROM
(`users` JOIN `users_exp`)
WHERE
(
`users`.`id` = `users_exp`.`users_id`
)
上面的视图就是 users 1V1 users_exp ,关联条件是 `users.id = users_exp.users_id`
所以称之为1V1关联，因为用户和用户扩展信息表是通过user id 进行关联的，一个对一个。
反之除了1V1，其它的都是1VN or NVN
在进行非1V1业务时，比如：老师和学生
老师有N个学生
学生有N个老师
学生列表
| ID | 姓名 | 我最喜欢的老师 |
| --- | --- | --- |
| 1 | 张三 | 熊雯 |
ID和姓名来自学生表，我的老师的名字来自老师表，通过中间关系表，多表联查形成上面的列表。
但是修改这个列表的时候，显然不能直接将老师的名字给改了并且更新到老师表中。
合理的需求是，可以修改学生的姓名，学生和老师的关系。
但你不能直接改老师名字，你能喜欢英语老师，别人也可以喜欢，你改了名，别人还咋喜欢，都不认识了。
好吧，扯这么多，就是希望大家不要在使用视图的时候陷入误区。
再看一个段子：
问程序员，你会啥？
我会增删改查。
问程序员，软件是啥？
软件除了增删改查，还是增删改查。
貌似听起来没啥毛病吧？
在实际企业级项目中，很少有功能模块是纯单表操作的，多多少少关联其它表的某些字段。
这时候除了增删改查，就是复杂的增删改查了，不是单表的增删改查。
一个业务，需要操作3张以内的表，我们可以简单的说这是一个简单的功能。
一个业务，需要操作5张以内的表，我们还可以说这是一个简单的功能吗。
5张表意味着什么？
5表联查，5表更新，5表。。。。尼玛想想都疼蛋。。。
PS：所以在设计表结构的时候不要将关系复杂化，应该遵循大事化小小事化了的原则，该冗余的地方就冗余，不要盲目套三大范式，你设计的表是给人用的，不是给老师打分的。
但是往往，肯定会遇到一小波业务就是有那么复杂，需要三表，甚至更多的表，联合作业。
甚至在复杂业务的系统里，这是家常便饭？
怎么破？
在经历了很多方案的来回推倒,重写,来回折腾之后最终决定如下!
以下方案完全是在无尽的折磨中,尝试出来的,没有参考任何第三方系统和设计,如果雷同,纯属山寨!
至于下述方案到底能支撑什么样的业务场景,各位智者见智,应该拥有无限可能!
EOVA视图处理的设计 V1.6
- 目的：让操作多表，像操作单表一样简单
使用思路
- 自建View 提供 元数据导入,支撑复杂的列表查询展现
- 复杂表单后端逻辑通过Aop增强(配合DIY_JS 操控前端)
- 超复杂的自定义按钮,自定义前端Form和后端逻辑
导入视图和导入普通数据表一样,没有什么特殊的地方!
列表查询和展现也没有什么特殊的地方
一个是form table
一个是form view
需求背景描述:
代码: com.oss.order.OrderIntercept By V1.6 OSS Demo
订单关联用户和收获地址:
orders 订单表
users 用户表
address 收获地址表
下面主要描述核心的也是最复杂多变的地方.
新增AOP:
/**
* 推荐使用Model来实现业务逻辑，万物皆对象，不要问我为什么！
*/
@Override
public String addBefore(AopContext ac) throws Exception {
Record data = ac.record;
// 获取用户信息 保存
Users user = RecordUtil.peelModel(Users.class, data, "login_id", "nickname", "info");
user.save();
int uid = user.getInt("id");
LogKit.info("新增用户成功：" + user.getInt("id"));
// 获取收获信息 保存
Address address = RecordUtil.peelModel(Address.class, data, "name", "full", "mobilephone");
address.save();
int aid = address.getInt("id");
LogKit.info("新增收获信息成功：" + aid);
Orders order = RecordUtil.peelModel(Orders.class, data);
order.set("address_id", aid);
order.set("create_user_id", uid);
order.set("update_user_id", uid);
order.set("create_time", new Date());
order.set("update_time", new Date());
order.save();
LogKit.info("新增订单信息成功：");
return super.addBefore(ac);
}
修改AOP:
/**
* 懒人做法Record，一条龙全部搞定，简单粗暴！
*/
@Override
public String updateBefore(AopContext ac) throws Exception {
Record r = ac.record;
// 获取用户信息 更新
Record user = RecordUtil.peel(r, "create_user_id -> id", "login_id", "nickname", "info");
Db.update("users", user);
int uid = user.getInt("id");
LogKit.info("更新用户成功：" + uid);
// 获取收获信息 更新(下面的特殊语法可自行研究源码)
Record address = RecordUtil.peel(r, "address_id -> id", "name", "full", "mobilephone");
Db.update("address", address);
int aid = address.getInt("id");
LogKit.info("更新收获信息成功：" + aid);
Db.update("orders", r);
LogKit.info("更新订单信息成功：");
return super.updateBefore(ac);
}
如上是不是分分钟搞定,复杂的多表业务逻辑!