这是一个创建于 880 天前的主题，其中的信息可能已经有所发展或是发生改变。
尤其是 spring security+spring boot ，虽然几行代码就跑起来了，但想改却很难，因为不知道约定了啥，背后偷偷给我跑起来个啥，只能官方文档加源码配合着研究，没觉得学习成本有降低。
最终搞了个七七八八，但对于整体的结构与数据流还是没有完全理解，因为 spring boot 的自动配置会检测条件什么的，造成配置的动态化难以捉摸，虽然类都静态写在那里，但会不会实例化还要跑起来才知道。
而且 spring 里普遍的各个重要类之间的关系比较复杂，个人感觉不是线性也不是树形，而是网状的，比较纠缠。
 |
1
Leviathann 2022-07-01 21:36:02 +08:00
这个应该是源自 ror 的理念
|
 |
2
FrankHB 2022-07-01 22:04:03 +08:00  2
没约定还不是一样要看文档来配置……
约定烂是另一回事，属于设计问题。 |
 |
3
wangkun025 2022-07-01 22:05:37 +08:00
我用的是 Ruby on Rails ，觉得这个理念挺好的。
|
 |
4
cheng6563 2022-07-01 22:09:44 +08:00
不约定，配一堆 web.xml ，application.xml ，jdbc.properties ，redis.json ，好玩不
|
 |
5
litchinn 2022-07-01 22:11:27 +08:00
理念优劣不清楚，但是人们更愿意使用 springboot 而不是回到配置 spring 的时候这是肯定的
|
 |
6
fzdwx 2022-07-01 22:16:41 +08:00
`而且 spring 里普遍的各个重要类之间的关系比较复杂，个人感觉不是线性也不是树形，而是网状的，比较纠缠。`
这个是不是因为找不到到底注入了哪个实现吧，哈哈。 |
 |
7
luob 2022-07-01 22:27:23 +08:00
你的感觉没有错，这确实是 spring 这一套最大的硬伤，但是同时带来的好处也是巨大的。
你也不好去指责它什么，因为它怎么选都是错的，所有框架都只能解决一些问题，并不能解决所有问题。 |
 |
8
renmu123 2022-07-01 22:30:45 +08:00 via Android
首次接触的人会很难受，习惯的人会很爽。
我是不太喜欢这种设计 |
 |
9
wolfie 2022-07-01 22:36:04 +08:00
看文档，或者点进去看所有可配置选项。
|
 |
10
Jooooooooo 2022-07-01 22:49:21 +08:00
spring 另外一个大问题时, 一旦报错, 找具体是哪里的问题很困难.
|
 |
11
frisktale 2022-07-01 23:29:45 +08:00
约定大于配置的思想肯定是好的，但 spring-boot 确实有点过头了。我最开始学 springboot 一脸懵逼，引入组件只能网上搜索，然后跟着教程写，但不知道为什么这么写。后面学了 asp.net core ，也是类似的思想，但清晰多了。
|
 |
12
Bingchunmoli 2022-07-02 00:02:09 +08:00
或者换种想法，如果不是约定大于配置，那么我们从什么地方了解到一个框架的使用以及入门，其实还是靠的是文档，大佬看源代码给萌新做视频，博客等等，不同的写法也可能导致萌新更疑惑，约定大于配置不一定是最好的，但是是当前情况下比较良好的解法
|
 |
13
dcsuibian 2022-07-02 00:09:41 +08:00
从 xml 时代到现在，肯定是更好的。
如果放开配置的话，可以，但能配置的东西实在是太多了。举几个例子： 数据库连接池：初始数量、最大连接数量、最大最小空闲连接、最长超时时间。 日志框架：输出格式、输出级别。 Servlet：请求大小、session 过期时间 再往细处想，一个 http 请求你就能配好多东西。以上还只是配置，那库的选型呢？ Druid 还是 C3P0 ，log4j2 还是 logback ，Jackson 还是 Gson 。选择面太广了。 |
 |
14
version0 2022-07-02 00:15:14 +08:00
就是没这个约定大于配置，还是得去看文档，熟悉过后，springboot 这种写法很方便
|
 |
15
daliusu 2022-07-02 00:23:38 +08:00
来写写 webpack 看看，你就知道约定优于配置究竟多好了，还没干活先配个一两天 webpack 吧，直到现在配置 webpack 都是常见八股文面试题呢
|
 |
16
wiix 2022-07-02 02:00:12 +08:00
spring boot 只是降低了代码量和入手，没有降低学习难度。
另外“看官方文档=学习成本高”不成立，看官方文档也学不会的前端框架贬低都是，看的想骂人😀😀😀 |
|
17
wiix 2022-07-02 02:02:14 +08:00
spring boot 只是降低了配置量和入手难度，并没有降低学习难度。
另外“看官方文档=学习成本高”不成立。看官方文档也学不会的前端框架遍地都是，看的只想骂人😀😀😀 |
 |
18
kongkongye OP @daliusu 让我想起了 vite 跟 webpack ，webpack 配置的确多，vite 却很简洁
|
 |
19
frankly123 2022-07-02 07:52:33 +08:00
这就是你几年经验的用处啊🐶
|
 |
20
RuLaiFo 2022-07-02 09:34:26 +08:00 via Android
@wangkun025 了解过 ror ，我有种这样的感觉，ror 的约定大于配置很严格，这样在开法时就能清晰的知道哪些是约定好的东西。但是 spring boot 的约定大于配置就比较灵活了，灵活就会导致边界不清晰，所以有些时候不清楚约定了啥，需要看源码。
|
|
21
wangkun025 2022-07-02 09:59:56 +08:00
@RuLaiFo 可能这就是我每次学 Spring Boot 都觉得痛苦的原因吧。
|
 |
22
DoctorDeng 2022-07-02 10:30:53 +08:00
肯定是约定优于配置的概念更好的，确实方便上手，对于有个性化需求的地方确实还是得看文档。
楼上有些说难学习的，多用用就好了。有了 Spring Boot 模块复用就非常方便了，我现在日常开放中，很多东西都是单独抽离成 xxx-starter ，其他项目只需要引入这个依赖就能够使用了，不像以前，导入依赖后还得配置一大堆东西 |
 |
23
mejee 2022-07-02 11:41:22 +08:00
不太喜欢 spring boot 那一套，虽然原因是自己没有好多学，感觉稍微用用还行，高级一点的定制化的用，有点束手束脚的
|
 |
24
veightz 2022-07-02 13:52:47 +08:00
对新手友好，对专家友好，但中间阶段的人很崩溃
|
|
25
kongkongye OP @RuLaiFo 的确过于动态化了，代码层面我更想静态一些，这样有助于结构的稳定与追溯。
spring 里框架有关的类我自定义个 bean ，就可能有其他自动配置失效了，除非很了解，否则这种未知会造成心里没底。 |
 |
26
james122333 2022-07-02 15:58:27 +08:00 via Android
其实框架都是约定的 只是占比还有实现差异
spring 糟糕的点在于註解表达力太差又太零碎 |
 |
27
ikas 2022-07-02 19:31:54 +08:00
spring 或者 springboot,人家提供自动化配置,也支持完全手动配置..
从来都是看人.你不想用约定,那完全可以用自己的思维配置 至于说什么 xml,注解,java..无非都是一种配置方式而已.. |
|
28
james122333 2022-07-02 19:49:15 +08:00 via Android
|
|
29
ikas 2022-07-02 20:58:08 +08:00
|
 |
30
wupher 2022-07-02 21:04:12 +08:00
在 RoR 之前，没有 Sring 或者 Spring Boot 时，Struts, hiberate 这些光设置文件就一堆 xml 。
那时 xml spy 真是必备工具。有时光搭个项目框架，就要花 1 天。 当前第一次学习 RoR 时，真是大受震撼。 |
|
31
kongkongye OP 有的人可能语言过激了，这里并没说 spring boot 的约定优于配置不好，只是一种设计上的吐槽与探讨，想想 npm 与 pnpm ，npm 并没有不好，但是针对缺点弄个新框架也未尝不可。约定其实就像软件设置里的默认值，只是软件默认值列表是可以直观展示出来并修改的，但 spring boot 里的约定太多太细了，关系错综复杂也不是一个简单的列表可以展示的，约定优于配置就是把双刃剑，因此后续或许某人就觉得这点不爽然后弄个新框架呢？开发技术是一直在进化的，不能因为一个东西自己用着挺爽就觉得一直不会变，不能变。
|
 |
32
cs419 2022-07-02 22:48:49 +08:00
spring boot 的思维 适合快速体验 某个框架
又比如 张三希望推广自己的开源库 做个适配 spring boot 的适配器 让别人能快速的 体验这个开源库 张三 写的 boot starter 如果是凑合写的，兼容性就差，要保证兼容性好，还得勤快的维护 用过 docker 的话 就有相似的感受 一行命令就能快速启动 mysql 快速的体验这个东西 但体验之后 如果是生产环境 还是 应当自己对 mysql 的配置文件 进行配置的 自己写 dockerfile 调试比较繁琐 同样的 用 spring boot 整合某个框架的时候 你要是想糊弄 就用自动配置 (有可能遇到与其他库冲突的问题) 想要深度定制 就自己基于 xml 的形式去配置 xml 虽然啰嗦 但每项配置都是你亲自加的 不会有暗坑 明坑的话 找解决方案容易点 用过 mybatis plus 与 flowable 一起使用 会冲突 好像是因为他俩 sqlSessionFactory 重复了 于是干脆都自定义 也不用他俩的 boot starter 了 |
|
33
james122333 2022-07-03 14:31:16 +08:00 via Android
|
|
34
james122333 2022-07-03 14:34:50 +08:00 via Android
|
|
35
james122333 2022-07-03 14:41:19 +08:00 via Android
|
 |
36
akira 2022-07-03 21:17:58 +08:00
开箱即用比什么都重要。 跑个东西还要配半天，这种没人会喜欢的
|
 |
37
nothingistrue 2022-07-04 09:39:14 +08:00
@kongkongye 约定优先于配置，不是约定代替配置，你要不乐意，完全可以手动配置自己搞。你所看到的复杂，跟约定优先于配置没关系，是配置本来就这么复杂，约定是降低，而不是增加了复杂度。你现在的看法，举个例子来说就是：不怪路本来就难走，而怪修路的没把路修好。
|
Select Language