若依框架真的好用吗有用过若依框架的吗说说感受？
若依是一个能用的东西。
仅此而已，远远谈不上好用。
挑几个我实在无法忍受的点来说。
1、ruoyi-vue版的菜单name重名404bug
这个bug是什么意思呢？
如果你有两个二级菜单，aaa--index，bbb --index，不好意思，其中一个会404，因为index重名冲突了。
没看懂？那我拿json结构举个例子。
[{
name: 'Aaa',
path: '/aaa',
children: [
{ name: 'Index', path: '/index' }
]},
{
name: 'Bbb',
path: '/bbb',
children: [
{ name: 'Index', path: '/index' } // 这个会404，因为name必须唯一，存在2个Index
]}
]
若依的菜单管理，配置的时候需要你填写的就是一个path，然后它直接取了path加首字母大写作为name。
但在vue-router的组件要求是name必须唯一。
我很好奇，若依在生成路由name的时候，为什么子菜单不能拼接上父级的name?
即变成
[{
name: 'Aaa',
path: '/aaa',
children: [
{ name: 'AaaIndex', path: '/index' }
]},
{
name: 'Bbb',
path: '/bbb',
children: [
{ name: 'BbbIndex', path: '/index' } //即子name包含父name，避免name冲突
]}
]
这个bug这么简单，但是就是没改。issue上不少人都有人提，然后一堆人的回复就是，name不能重复，换一个不重复的path。
2、代码生成器默认模板
我相信学Java的人都听过一堆的的VO、PO、DTO等各种O。
但实际使用上，非常多人喜欢Entity一用到底。
事实上我也觉得简单的项目弄那么多O概念出来就是给自己找麻烦。
但是，我依然觉得，一个CRUD至少要用到2个O。但是请你看下去，大概率不是你平时看到的2个O。
先举个例子吧。
假设有个表，就叫demo吧，对应的类是
public class Demo {
private Long id;
private String searchField1; // 需要作为搜索条件的字段
private String searchField2;
private String searchField3;
private LocalDate searchDate1; // 需要做为搜索条件的时间字段
private LocalDate searchDate2;
private LocalDate searchDate3;
private String field1; // 不需要搜索的字段
private String field2;
private String field3;
}
常见的错误用法一
生成一个Demo(Entity)外，还另外生成一个DemoVO（也可能叫其他名字）。
但两者字段几乎就是一模一样。
所以实际用的时候也就是各种Bean.copyProperties(source, target) copy来copy去的。
这也是大家往往觉得这些各种各样的O是垃圾的主要原因。
常见的错误用法二
若依里就是这样。
默认生成的controller里CRUD都是用一个Entity从头用到尾。
public class DemoController {
public TableDataInfo list(Demo demo); // 其他方法没错，就错在list方法的请求参数不该用User
public AjaxResult getById(Long id);
public AjaxResult add(Demo demo);
public AjaxResult update(Demo demo);
public AjaxResult delete(Long id);
}
其他方法都没错，增删改都是围绕着Entity来做的，直接用Entity多省事。
但是，list是例外。list的返回可以返回Entity，但是查询参数绝对应该独立一个QueryParam对象。
回头看我前面列出的Demo对象，为什么我要刻意强调 searchField、normalField 呀？
因为一个表那么多字段，不是所有字段都需要作为搜索条件的。
若依自己也是知道的，所以代码生成器可以让你选择哪些要作为查询条件。
再来看时间相关的查询条件，这是用between最多的。
Entity上时间是一个字段，但是查询的时候很多时候传的是一个date range。
这就不对应了呀。怎么办呢？
若依的做法就是用Map params，每个Entity内都嵌入了一个Map params。
其实我觉得，在这里引入一个QueryParam是最好的。
勾选了哪些字段需要用来做查询条件，就专门把这些字段生成一个QueryParam。
这就是我开头说的2个O，Entity和QueryParam。
我的观点
1、生成2个字段一模一样的Entity和VO，copy来copy去，是很蠢的。
2、list用Entity来做查询条件，也是很蠢的。
我的建议
1、如果你的entity和各种O大差不差，就别折腾了，一个Entity就够，别要各种O了
2、专门生成一个QueryParam给list做查询参数用。
我推荐的Controller
public class DemoController{
public TableDataInfo<Demo> list(DemoQueryParam queryParam); // 参数用queryParam，返回用Entity
public R<Demo> getById(Long id);
public R<Void> add(Demo demo);
public R<Void> update(Demo demo);
public R<Void> delete(Long id); // 不在意返回结果的话，可以用Void，return R.ok(null)即可
}
3、超喜欢用Map
前面的代码也给出若依的默认代码了，超喜欢在各种地方用Map。
比如Controller里接口的数据接收用Map（我指的是BaseEntity里有一个Map params），返回用AjaxResult?
我实在搞不懂，为什么是用AjaxResult，这样swagger文档还有什么意义？
根本出不来返回报文的结构呀。
4、项目应该SDK化
市面上大多数若依这样的项目，大家的使用方式就是把若依的项目clone下来，然后自己开多一个module，甚至直接在ruoyi-admin模块里继续加自己的业务代码。
这样的做法，坏处非常明显。
1、很难（甚至无法）继续同步若依的更新。
2、在自己的业务项目代码仓库里掺杂着大多自己本不需要关注的框架源代码
3、我相信很多人在公司里都不只负责一个项目，这样就把若依相同的源代码拷贝了好几次
试想一下，你使用springboot的时候，不是引入dependencies，而是直接把springboot的源代码放到项目里，这画面美不美？
所以我很好奇，若依（不仅仅是若依，应该说国内这一类项目都是如此）为什么不把项目sdk化，这样大家都可以建一个几乎空白的项目，然后引入若依的dependencies，就可以只关注自己的业务代码了。
我们现在就是这样，把若依的源代码打包jar后deploy到私有的nexus。
想魔改就魔改，以后要同步更新若依也很方便。
