自己给自己做的项目：
无 service ，无 dao ，只有 controller 和 util
controller 的 action 访问一切，mybatic 的 mapper 直接放 controller 上或在 controller 手写 sql 。c 井就直接 dapper 放 controller 上访问任意，加入 redis 什么乱七八糟的各种库都在 util 或 controller 的注入上。
如若发现复用的获取数据或其他逻辑，则只把复用的提出来封装 service 或者 bll ，所以这一层顶多是复用的，如果不复用坚决没有这个，就是一个方法在很多地方都在用。
目的：看代码的人打开一个文件，查看一个方法，就能看出到底是在做什么，改动的时候非常方便。
如果一个方法很长，使用代码折叠 region 和详细注释。
如果抽象类确实有多个实现子类，才使用继承，而且一旦使用抽象类，必有多肽，绝对有多个不同子类逻辑会调用。
否则类就是类，基本不用 interface 。
异常统一处理。

给公司做的项目
dao ，service ，controller ，util ，bean ，各种加。
一个方法代码不超过 200 行，各种封装函数。
多使用 interface 和 impl ，管球他基本上只有一个子类。
dao ，service ，bean 什么的，每一层 interface ，impl 起码两个文件。
加的越多越复杂，越提现分层思想，越增加代码行数，文件数量也大，越在 jira ，禅道，tpad 这种东西上可以写工作量。
绝不做统一异常处理，controller 每个都 try catch ，耦合度越大越好。
如若 util 层增加一个接口方法，或者接口方法增加参数，连着 dao ，service ，controller ，bean 等到处修改。
这样在 git 提交的时候，发现改动文件多，在 jira 上工作量就写得漂亮。
关键是，整天开会，开完就这么写，速度也不快，让别人感觉自己非常忙，别人拿代码一看，确实封装方法多，绕来绕去，看一个功能起码打开五六个文件。
以前自己不喜欢这么做，但是公司的规范，企业文化把人逼成这样。

目前被他们搞疯了，已经去精神病院治疗抑郁症。