Colorful
Colorful
对于单表的 CURD 简单业务，开发流程比较固定，我们都需要如下操作： 1. 配置路由，基本上就是列表页面、新增页面、编辑页面等； 2. 编写模型层，提供基本的 CURD 方法； 3. 编写视图层。 期望能够提供代码生成器来简化重复的开发步骤。
LinCMS已经内置好了 LocalUploader 和QiniuUploader；希望社区有小伙伴可以新增 MinIO、ftp 的文件上传实现类。
对于数据的软删除，`Lin CMS`是通过`delete_time`字段是否为`null`来判断的。因此所有的查询语句，都会拼接上一个 where 条件`delete_time is null`。这种做法会引发很诸多性能问题： 因为`delete_time`默认值为`null`，可以为 null ，会导致查询效率大打折扣，`explain`会走全表扫描：  推荐增加 `is_deleted` 字段来做删除标识，这种是比较常用的逻辑删除做法，查询性能上至少比现在的做法要好： ```sql is_deleted int(1) NOT NULL DEFAULT 0 COMMENT '0：正常 1：已删除' ``` 参考链接： [性能优化案例分析之一：软删除是慢查询的罪魁祸首？](https://ruby-china.org/topics/34540) [小心 MySQL Soft Delete](https://www.jianshu.com/p/aeff2a297d62)...
assets 目录用作本地文件上传，应该移到项目根目录 https://github.com/TaleLin/lin-cms-flask/issues/127
对于数据的软删除，`Lin CMS`是通过`delete_time`字段是否为`null`来判断的。因此所有的查询语句，都会拼接上一个 where 条件`delete_time is null`。这种做法会引发很诸多性能问题： 因为`delete_time`默认值为`null`，可以为 null ，会导致查询效率大打折扣，`explain`会走全表扫描：  推荐增加 `is_deleted` 字段来做删除标识，这种是比较常用的逻辑删除做法，查询性能上至少比现在的做法要好： ```sql is_deleted int(1) NOT NULL DEFAULT 0 COMMENT '0：正常 1：已删除' ``` 参考链接： [性能优化案例分析之一：软删除是慢查询的罪魁祸首？](https://ruby-china.org/topics/34540) [小心 MySQL Soft Delete](https://www.jianshu.com/p/aeff2a297d62)...
`LinCMS`已经内置好了 `LocalUploader` 和`QiniuUploader`；希望社区有小伙伴可以新增 MinIO、ftp 的文件上传实现类。
例如如下代码： https://github.com/TaleLin/lin-cms-spring-boot/blob/2ff4bf8bf1a2d347af3a1f70416a121481a45add/src/main/java/io/github/talelin/latticy/controller/cms/AdminController.java#L72-L78 我们的项目中的示例代码，但凡碰到分页的相关的传参，都是采用这样的方式定义，将分页的查询参数，定义在了方法参数签名中的，这样虽然比较直观，但无疑增加了代码量。 我们可以封装一个基础分页DTO（例如`BasePageDTO`），在 DTO 中定义这些属性。如果有额外的参数，可以继承该 DTO。这样既减少了代码量，也提高了代码的封装性。
我们内置的管理员用户表为 `lin_user`，对应的模型层命名为 `UserDO`、服务层命名为`UserService`、控制器层命名为`UserController`。 当我们开发一个独立的 CMS 项目，是没有什么命名冲突问题的。 但对于一个小型项目，我们想使用 LinCMS 快速开发 C 端用户接口，如果 C 端用户表名称为 `user` ，那么对应的模型层、服务层等等就不能使用`UserDO`、`UserService`这些来命名，可否考虑把`lin`内置的类命名加一个前缀做区分？（例如`LinUserDO`、`LinUserService`）。这样`C`端用户相关的类，就不用考虑命名冲突问题了。也不会因为系统中`user`相关的命名太多，对后续的维护者造成困惑。