有关裁剪定制，如果用户觉得开箱提供的组件不好用，可以利用 Spring 的容器机制和 bean 做扩展。 如果用户觉得所有组件都不好，那确实 Jmix 不适合。

我们的理念是做为框架，它应该是一种最佳实践集合，给用户一套久经验证且大多数用户认可的技术栈产品。

比如全文搜索，Jmix 用的就是挂 ES，这个是团队认为比较稳定、大多数开发者认可的方案。但是用户完全可以利用 Java/Spring 的可扩展性支持 Solr 或其他方案。

有关做到最后， 你说的不错，最终的产品就是一堆上层组件和底层基于 Spring 的核心框架，这是 Jmix 价值的 2/3，支持开发者用最熟悉的技术和即用型组件能快速出结果。另外 1/3 就是开发者工具-Jmix Studio，开发全流程的加速器。

大部分的软件公司都会考虑组件化，为了复用，为了模块化，不论用不用 Jmix，用不用Java，最后都是一堆组件。。。

【 在 oldwatch 的大作中提到: 】
: 这种偏业务层面的框架
: 其实最大问题是如何方便的裁剪定制
: 比如全文检索我直接走RDBMS的扩展语法搜行不行？
: ...................
--
FROM 125.34.17.*