Solon 2.0 特性与需求收集

暂无描述。

配置文件 idea 没提示

1. 部分调整规划草案 //::已全部完成调整

相对明确的：

添加 Solon.context();
移除 solon.extend.sessionstate.* (已有 solon.sessionstate.*)
移除 solon.ext.* （已转到：solon.core.util.*）
更名 solon.extend.aspect[弃用] => solon.aspect[新增] [无感+] //ok //ok
更名 solon.extend.health[弃用] => solon.health[新增] [有感-] //ok //ok
更名 solon.extend.hotplug[弃用] => solon.hotplug[新增] [有感-]
更名 solon.extend.properties.yaml[弃用] => solon.config.yaml[新增] [无感] //ok //ok
更名 solon.extend.servlet[弃用] => solon.web.servlet[新增] [无感] //ok //ok
更名 solon.extend.staticfiles[弃用] => solon.web.staticfiles[新增] [有感-] //ok //ok-
更名 solon.extend.cors[弃用] => solon.web.cors[新增] [有感-] //ok //ok-
移除 Aop，由 Solon.context() 替代

相对不明确的：

solon.extend.* 全更名为：solon.* ? //调整部分

2. 插件命名规范：(插件越来越多，怕起冲突) //::已全部完成调整

适配插件命名
- *-solon-plugin
- *-solon-cloud-plugin

3. 插件类包命名规范：(插件越来越多，怕起冲突) //::已全部完成调整

容器能力对接，包名风格：
{xxx}.solon ? //例：cn.dev33.satoken.solon
接口适配对接，包名风格：
org.noear.solon.extend.{xxx} ?
org.noear.solon.cloud.extend.{xxx} //例：org.noear.solon.cloud.extend.water
org.noear.solon.{ddd}.{xxx} //例：org.noear.solon.cache.redis

4. 增加响应式系列支持

5. 增加AOT编译便利支持

移除 Aop，由 Solon.context() 替代 ? Aop 这个名字让人很疑惑，个人感觉应该替换掉

Ioc/Aop 里的 Aop 。。。目前，Aop 类已标为弃用。。。待 2.0 时会删掉了（明年）

参数校验好像不能分组

验证分组，一般有哪些应用场景啊？

例如：新增操作和更新操作，需要验证的字段是不同的，更新操作中id字段是必填，新增情况下可为null

有个方案可以试试：有差异的字段，把它独立为参数

效果

public void add(@Validated User user){
    
}

@NotZero("id")
@NotNull("id")
public void update(Long id, @Validated User user){
    
}

确实也可以考虑一下，要不要加组：）

我建议加一下。

例如在分步表单填写的业务：第一步填写 a/b/c 三个字段数据，第二步填写 d/e/f 字段数据，这两个步骤需要对不同的字段校验。如果没有分组，那就需要多创建类来进行字段检验。有分组的话，就可以用同一个类，里面包含 a/b/c/d/e/f 字段，将字段分组检验。

好，加一个。。。1.9.3 会加上

1.9.3-M2 版已添加分组支持。麻烦试一下

现在有分组了：）

启动日志控制台需要添加SOLON banner标识

个人喜欢底调的口味

部分命名规范调整

插件命名规范：(插件越来越多，怕起冲突)

官方适配插件命名
- solon-plugin-*
- solon-cloud-plugin-*
第三方适配插件命名
- *-solon-plugin
- *-solon-cloud-plugin

插件类包命名规范：(插件越来越多，怕起冲突)

容器能力对接，包名风格：
{xxx}.solon ? //例：cn.dev33.satoken.solon
接口适配对接，包名风格：
org.noear.solon.extend.{xxx} ?
org.noear.solon.cloud.extend.{xxx} //例：org.noear.solon.cloud.extend.water
org.noear.solon.{ddd}.{xxx} //例：org.noear.solon.cache.redis

建议减少默认对其他包的依赖，如freemarker、okhttp等，我不使用，打包的时候不希望带上。

快捷包，只是给用户带来方便。。。你可以用 solon-lib 为基础进行装配。

或者，按需一个个插件进行装配

包装类 org.noear.solon.core.BeanWrap 可以改为泛型，使用的时候更简单

bw.get() 时会自动转的，有泛型特性

配合 Aop.getAsyn IDE 能自动感知类型

   public static void getAsyn(Class<?> type, Consumer<BeanWrap> callback) {
   public static void getAsyn(Class<T> type, Consumer<BeanWrap<T>> callback) {

请问是为啥做这个项目，有什么愿景。很担心用着用着不维护了。

就是想要：包很小、启动更快、内存更少：）。

任何东西都有生命周期，适者生存！如果它不“适”了，自然会消失；如果它一直“适”着，也就会一直存在着。。。主要还是看它的特性有没有生命力。

有支持es的插件吗

es 的客户端可以直接用的；；；或者也可以看一下：https://gitee.com/noear/esearchx

tencent Polaris

这个已经适配得差不多了；正在测试中：）。。。希望一起出出力：）

1.11.6-M1 已完成北极星的适配。可以试用一下。。。具体的测试项目：

https://gitee.com/noear/solon-examples/tree/dev/9.Solon-Cloud/demo9024-config-discovery_polaris

@Mapping("/xlj")
@Controller（）

不能写成
@Controller("/xlj")

不能：）

GVP noear / solon

内容风险标识

评论 (29)