FreeSql 项目大概在20天前想着要做的，今天发布0.0.4在群里被一位大神讽刺。
这位无名氏哥们的观点，先声明这不是找安慰的文章，更加不是报复打击的目的。
1 所以这个比EF好在哪里
2 毕竟EF是官方的技术，你自己造的轮子得说明自己哪里不是重复造轮子，而不是问已有的轮子到底怎么样
3 EF完全可以胜任并且超出一个ORM框架需要的所有功能
4 你可以觉得EF不够好，自己做一个更好的，但是这建立在你能指出EF哪里不好的前提下
5 另外插入一个话题，[图片]这个项目引用 很显然 这违背了.NET Core的小包思想，四个字，按需引用
6 这根本就不是什么拆包的问题，而是在开发的时候就是小包，你不了解.NET Core的思想，每必要非得说自己是正确的，有人教你，你就虚心接受，没什么大不了的
7 你target了.NET Standard，却走的是原来的那一套思路，
8 在接受一个新的平台的时候，你需要接受它的思想
9 不要重复造轮子，你如果觉得ef有缺陷，哪不好，自己提issue，给pull request，如果你觉得ef一无是处，你自己做，那也得说明它比ef好在哪里，是吧
10 你和ef的区别在于你把sql语句暴露出来了，而ef是使用IQueryable来完全封装sql的
11 IQueryable是一个标准接口，你要标新立异，本来就是兼容性很差的
12 你觉得微软不对你可以别用微软，但是你用微软你就得遵循用微软的人在遵循的标准
13 ORM框架本身，并不是一个功能性的东西，就是提供一个优雅的coding style，但是你的ORM框架，却忽略了coding style的问题
14 现在.NET上的ORM框架、甚至是一些no sql的数据驱动，他们的查询操作，主流的，你觉得有几个不是实现IQueryable接口的？
15 你标新立异，就代表着现存项目没有这个开发成本来重构成基于你的框架的版本，新的项目也无法接受选型你这个框架的风险
16 不实现IQueryable接口的查询API，实际项目无论是迁入到你这个框架，还是从你的框架迁出到别的框架，都有巨额的重构成本
17 你写出来一个东西来符合自己的理解，自己觉得更优雅，但是实际项目选型的时候要选用你的框架，会有这些问题：
1)你的文档中没有任何对比说明你的框架哪比EF更好
2)你的框架迁入迁出成本太高
3)你的框架缺乏学习资源
4)你的框架缺乏可靠的社区支持
18 是，有了.NET Core，微软拥抱开源了，.NET开发者都可以融入开源社区了，但是你得知道什么是开源社区，开源社区什么东西能好，什么东西得避免，开源社区的运作思想，而不是，哦，我写一个库，放github上，就是开源，你造轮子也得按照基本法，不要重复造轮子
19 [图片]从关键字搜索来看，这个项目里没有任何连接池控制的逻辑
20 我不知道你的项目里有没有实现数据库的版本控制的逻辑，如果没有，那你真的该去好好了解为什么要用ef，如果有，那么你是真正的勇士，花了一大把时间来重复造了一个很繁琐的轮子
21 算了，你自己要花时间，谁也拦不住，但是当成果被认可的程度没有达到你的预期时，请不要忘记我曾经提醒过你，大家都是程序员，坑都得自己跳一下才知道深，这个我是理解的
老哥应该是怕我被坑，我觉得做项目不容易，愿意开放源代码不应该鼓励吗？下班的时候和这位老哥聊了半小时，我很感激你的提醒，但是我需要更多的应该是认可。
咱们无偿开放源代码容易吗，好好给一点点鼓励就行，.net社区的未来才会更好。
项目仓库：https://github.com/2881099/FreeSql
目前版本 0.0.4，目前可用性已经挺高了，如果觉得不容易，请给予一星，谢谢🙏
来源：oschina
链接：https://my.oschina.net/u/4259850/blog/4463256