为什么我劝你放弃mybatis
发布网友
共1个回答
热心网友
mybatis，作为一个SQL模板引擎，被广泛应用于企业中，尤其在追求数据库表“扁平化”的趋势下，它因其简化SQL拼装而备受推崇。然而，我反复强调，mybatis并非理想的DAO解决方案，它让代码变得混乱且重复工作增加。使用mybatis时，代码可读性和维护性大打折扣，主要体现在以下几个方面：
1. **mybatis的本质与需求不符**：作为一个SQL模板引擎，mybatis并没有解决DAO层的核心需求，即高效、灵活地操作数据库。如果实现同样的功能，使用JDBC API或更轻量的框架如nutz更为合适。mybatis生成的代码往往需要额外维护，包括数据库DDL、文档、SQL XML文件、Entity代码、dao（或mapper）接口等，这实际上增加了开发者的负担。
2. **XML作为模板语言的弊端**：mybatis使用XML作为模板语言，这在可读性和维护性方面存在严重问题。XML结构复杂，难以阅读和理解，而直接在Java代码中拼接SQL语句反而更加清晰。XML中对特殊字符的转义处理也降低了代码的可读性。
3. **封装问题**：在mybatis中，对于参数的封装方式（如注解、TO对象、map、下标）都存在一定的局限性和不优雅性。这要求开发者在每次接口变更时，需要处理额外的封装问题，增加了开发和维护的复杂度。
4. **代码生成的问题**：mybatis的代码生成机制是“编译时”，在需求变更时需要重新生成代码，这与现代开发模式（如运行时生成代码）不相适应，增加了维护成本和风险。
5. **调试与重构**：在mybatis中，SQL代码嵌入在XML文件中，这使得调试变得困难。相比之下，直接在Java代码中编写SQL语句，利用IDE的语法提示和重构功能，可以更有效地进行调试和重构。
6. **性能与缓存**：mybatis在性能和缓存机制上与Hibernate等其他ORM框架相比存在差距。例如，Hibernate提供了更灵活和强大的缓存机制，而mybatis在缓存管理上相对复杂且不够直观。
7. **分表、分库、审计、全文索引等高级功能**：在这些领域，mybatis的实现往往不如其他框架，如Hibernate，提供直接支持和更高效的解决方案。
8. **代码质量与实现**：mybatis的某些实现可能存在设计上的瑕疵，例如在数据加密时的实现问题，这反映了其在某些关键功能上的不足。
9. **关联查询的复杂性**：mybatis在处理关联查询时，与传统方法相比更为复杂和繁琐，这了其在处理多表关联时的灵活性和效率。
10. **文件管理的困扰**：mybatis导致的文件分散管理问题，增加了查找和维护代码的难度，与现代开发的模块化和集中管理原则相悖。
综上所述，尽管mybatis在简化某些开发任务上具有一定的优势，但其在代码可读性、维护性、性能、高级功能支持和代码质量等方面存在明显不足，这使得其逐渐成为开发者讨论和避免的对象。选择技术时，应根据实际需求和项目特点综合考虑，避免盲目跟风或迷信某个框架的“优越性”。
