不知道从什么时候开始，spring 好像已经统一了java开发的规范，而且这种统一 给大部分开发者都带来了一些心理上的认知错误（请允许我用错误这个形容词），比如：
- 一定要有ioc，aop等
- 一定要兼容很多其他的包
- 功能必须越多越好
其实，不得不说，这是我们自己把路给走窄了，针对上面的5点，我有几句拙见：
一定要有ioc，aop等
IOC的存在是为了 方便替换实现类，以及绑定其他功能到bean上面，但是我们仔细想想，真的每一个对象 都需要用IOC吗？我敢打赌，大部分开发者 都说不出来IOC的具体意义是什么，又或者即使说出来了，也不是自己内心的真实体会，因为他们在实际开发中根本没有体会过IOC解决的那些问题，这难道不足以证明IOC被滥用了吗？
AOP的存在是为了监听某些方法，可以看作是方法级别的拦截器，他的底层原理也很简单，就是用动态代理，或者其他的技术 来生成字节码级别的子类，在某些情况下确实很有用，比如事务监听，以及监听某些方法的出入参 和 执行状态等。
思考点：真的有必要，只要开发项目，就把这两个特性弄进去吗？
一定要兼容很多其他的包
这应该是spring带来的最大的误解了，生态强大，兼容很多三方工具包，但是 不知道大家有没有想过，spring他只是用java开发的一套实现特殊功能的类库，说到底他就是个类库，他不是操作系统，所以生态这个说法 从何说起呢？任何开源项目都是可以独立使用的，kafka，mybatis，jedis等各种常用的项目，哪一个是必须依赖spring的？ spring只是做了一件事，就是做了一个二次封装，让大家在用的时候可以采用ioc的方式把 接口注入进来。
思考点：这些所谓的强大生态，到底是spring的生态 还是java的生态？
功能越多越好
这个好像不是spring带来的锅，应该是技术人员的思维习惯所带来的一个误区，他们总是对那些操作起来复杂，普通人完全看不懂的东西 有一种莫名的信仰（我知道不是全部，但确实存在很多），这种思维衍生出来的另一个思维 就是 功能要多，恨不得一个东西解决所有事情，这也是spring全家桶可以一统江湖的最大原因，但是功能多了 带来的一个负面影响就是累赘也变多了。
思考点：功能到底是越多越好，还是我们需要的功能全都有，不需要的功能全都没有 比较好？又或者可以根据自己的意愿来决定 这个项目中要那些功能比较好？
另一种流派
上面提到的这些问题，其实早就有人注意到了，并且做出了自己的解决方案，这种解决方案有一个专用的名词“轻量级框架”，其实就是功能少的框架，但他的设计思路依然是 一个框架解决大部分事情，只是把自己认为不需要的功能给去掉了而已，并且在实现上 用了最少的代码量，让打出来的jar包变的更小。
个人认为，这种方案还是有点治标不治本，只要他走的还是 一个框架解决大部分问题的路子，那么功能早晚会越来越多的，到了最后 就是另一个spring。
直接抛弃框架的概念
我经常在想，为什么一定要用框架？为什么不能从功能需求的角度出发 去思考问题，选择合适的jar包？ 举一个很简单的例子，比如我们现在需要开发一个网站，那么我们可以统计一下他需要的功能，比如统计结果是这样的：
- 他需要对外提供接口，所以IO肯定少不了的
- 他需要对数据库进行操作
- 需要用到缓存
针对这些功能，我们去选择合适的开源项目来满足我们的需求，比如就刚才这个需求，完全可以用【Tomcat，Mybatis，Jedis】来实现，我不觉得会有什么问题，也不会比用spring多写多少代码，甚至还可能少写，因为节约了大量的配置时间。
为什么我们就不能像这样，玩一玩搭积木的游戏呢？ 非要买一个庞大的成品回来玩，而且这个成品里面还有很多不需要的功能，在某些时候还是累赘的功能。
进一步的思考
后来我渐渐地想通了一件事，无论是一个框架解决所有问题，还是完全抛弃框架的概念，都是在走极端，我们是不是可以寻找到一条折中的道路呢？我们可以把 开发一个web后端 必须要有的功能统计一下：
- 需要一个IO来收发请求
- 收到请求后最好可以 分发到指定的方法上，并且自动验证参数
- 需要对数据库进行操作
我们可以按照这三点，做出一个骨架，然后让开发者自己去填充合适的皮肉和内脏（有人可能会有疑问，觉得自己填充很麻烦，对于这种疑问 可以翻回去看一下上面 关于生态的那一栏，我们要相信java的生态的多样性，一定不会让你手工实现太多没必要的东西的）。
这也是我发起Magician这个开源项目的初衷，他看起来很弱小，但是已经很好的实现了上面提到的三个功能，并且这三个功能是分开的，除了选2的时候必须选1之外，其他的所有组合方式 都是完全可以的，甚至可以只选择1 或者 3.
无耻的自荐一下
Magician是一套骨架项目，只能实现最基础的web后端，但是可定制化非常高，如果你不喜欢这三个骨架中的一个，那么你完全可以用你喜欢的那个来替换，比如：
- 如果你不喜欢我的IO框架，那你可以用tomcat + 我的数据库操作
- 如果你不喜欢我的数据库操作，那你可以选择我的IO + Mybatis
- 如果你三个都不喜欢，那我就没办法了，O(∩_∩)O哈哈~
至于生态问题，是非常好解决的，还是那句话，我们要相信java生态的强大，不要被某个框架给捆死，世界本身就是多样性的，比如：
- 需要用redis的时候，你可以自己引入Jedis，Redisson，lettuce等
- 需要用消息队列的时候，你可以自己引入kafka，ActiveMQ，RabbitMQ 等官方jar包
- 需要从后端发起http请求，你可以自己引入okHttp，HttpClient 等
可选范围真的非常丰富，多种多样。
最后，既然我已经无耻的自荐了，那我就再无耻一点吧，这个是项目的官网：magician-io.com