任何事情都是两面性的，Spring类框架提供了一些基本的功能（特别是程序管理功能，包括Bean,事务，连接池),为系统的搭建和开发提供了很大便利性，但同时也失去了灵活性和可控性，特别是对于开发人员来说，这种可控性是很致命的。
Spring的这种管理功能大多依赖于配置文件，但现代系统开发，特别是分布式系统来说，配置应尽量数据库化，而不是文件化，还必须配合预编译。hibernate由于其内存数据库风靡一时，就是因为其提供的功能虽然强大，但过于复杂的配置和一些多余的功能，反而让其慢慢失去了优势，所以更为简单的mybatis之类的开始流行，因为对于开发人员来说，可控性和灵活性始终是非常重要的。是用实体还是直接用数据集记录始终都是各有利弊，当然，最终的选择其实是取决于你的需求。
Spring这类框架在分布式开发中，其强大的管理能力，注入能力，其实是没有什么优势的，因为分布式应用一定面临着两个基本的切割，一个是纵向功能切割，代表是微服务，另外一个就是横向切割，这个主要是面向数据。Spring包括mybatis这类组合，对于功能切割还行，但对于横向切割来说，很多提供的功能就是多余的了，开发人员必须使用最原始的方法来达到目的，比如使用jdbc,自己管理bean,实体，自己控制事务。
很久前写过类似的文章，我是不主张spring的这种注入功能的，虽然可以提供一定的方便性，但其实是以降低性能，增加复杂度和程序风险为代价的。因为现在的系统设计基本都需要以SaaS化或者分布式为导向，一些模式，包括一些原来在程序及的注入功能，现在都需要提高到业务层面上来，比如订阅功能，现在都是在业务层级上实现，用专门的消息队列进行处理，原来要注入的功能，现在在业务数据层面上进行（可以用专门的系统功能来订阅处理这种功能），代码级上的注入需求其实非常少。另外，由于横向扩展的需要，老式的AOP模式，用处极其有限。
当然，框架局限是必然的，也不可能要求框架能满足所有的需求，但这同时说明了，开发人员在遇到难以处理的问题时，绕开框架的束缚就是必然的选择。