强烈建议 Symphony 抛弃某些固执的过去，拥抱 Spring MVC，Spring Boot，Spring Cloud。然后再就是前后端分离。
强烈建议 Symphony 抛弃某些固执的过去，拥抱 Spring
本贴最后更新于 1383 天前，其中的信息可能已经时异事殊
-
Sym
523 引用 • 4581 回帖 • 692 关注
相关帖子
-
Spring 对于 sym 的业务来说太厚重了，Spring Boot 中大量的“没用的”代码（自动配置等方便开发者的配置和大量依赖），分布式也不仅只有 Spring Cloud 一种，Dubbo 也可以，适合自己的才是最好的。
D 在 https://hacpai.com/article/1403847528022 中写到自己开发的 Latke，用 JSON 做实体，是非常有趣的想法，在我看来破而后立是非常有趣且大胆的尝试。
固执于一种语言，一种框架，而不是业务本身，反而有些本末倒置了。
1 回复1 操作fpdan 在 2020-07-06 13:17:17 更新了该回帖 - 其他回帖
-
感谢建议，很高兴能和你讨论这个话题。
业界主流框架并不是所有项目的唯一选择，我认为使用自研框架更能体现产品的价值，这些不是“固执的过去”，而是对未来的考虑，所以 Latke 框架也是在逐步升级演进的，设计方面尽量考虑降低用户学习上手曲线，不存在高阶复杂的概念，仅围绕 HTTP 协议作为端点发布。
从 Spring 家族发展史我们可以看到，近 15 年它的发展迅猛，架构用法变化很大，包括一些周边生态项目被废弃。使用 Spring 全家桶的优势是能够快速让大多数人上手，但带来的问题也很明显：难以保证产品质量，依赖项太多，版本兼容上也不可能做到完全融入用户的架构体系。既然还是要用户折腾，那折腾简单的框架不是更容易么？从过去 5 年 Sym 的用户反馈上看，几乎没有人抱怨过框架开发方面难以上手，Latke 本身也没有出现无法支撑应用场景的问题，所以其实并没有足够的理由来支持切换框架。
前后端分离对于论坛社区类型项目并不是最优解，PC 端和移动端使用服务模板更好一些，如果要提供前后端分离，也是单独走 API 做一个端（多半是在移动端来做，可以是小程序，也可以是 APP 等），但项目主体还是服务端模板优势明显一些。
总结一下，我们的目标是做好一款用户体验优秀的现代化社区论坛系统，技术只是实现它的手段，并不是我们的目标（何况有很多优秀的社区系统并不是 Java 写的，甚至所用的语言和框架也不是主流的），所以“固执的过去”并不是那么重要，重要的是如何在用户体验方面做到极致，接近这个目标后再考虑技术层面的重构也不迟 🙏
1 回复说的对，目前主要是功能和使用体验最重要。体验牛逼，用户量会倒逼技术架构的演进。做产品还是要客户第一，优先满足业务需求cbam • -
并不新颖，就是动态语言的常用做法。
其实 controller 不怎么修改实体的，多数情况下就是拼接，然后传到 view。
而且动态语言的哈希表操作更容易，不比对象复杂。
view 那边因为模板引擎会在 obj.a 和 obj.get('a') 里面选，所以是兼容的。
- 查看全部回帖
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于