ABP会臃肿吗？

有了ABP，还要学其他的框架？

　　我有时候在想在JAVA领域，Spring基本一统天下，新手也好，高手也罢都在学习、研究和项目实战。也就是说其实对与应用开发，Spring已经是绕不开的框架，不管是单体还是微服务都可以轻松胜任，学了Spring在JAVA开发层面，其实你可以完全不需要去学习其他的任何知识点，也能参加工作（当然不包括数据库和前端，我这里指的是JAVA语言本身）。

　　那么在.NET有没有类似Spring的框架，让.NET学员学完之后也可以胜任任何.NET工作，甚至能胜任架构师的角色，我觉得对于开源的ABP vNext来说，是完全可以做到的。因为它足够简单，上手非常容易，只要入门之后持续一段时间，我们就可以不断地在实战中逐步深入，重要的是开源的信息量足够一个架构师去模仿和学习，不管内部的模块化设计理念，还是模块化安装和删除的方式，都是一个理念活生生的落地代码，看得见摸得着，甚至我有时候觉得，只要学好ABP其他的框架可学可不学，不学是因为其他的框架从综合素质来说，目前还没有看到一个框架在应用层面可以和ABP媲美（.NET领域），没有夸张地说没有之一。学是因为不管是任何开源的框架都可以被ABP吸收并蓄，只要我们自己懂得ABP的框架规则，我们的集成是分分钟的事情。　　

　　所以，我的结论是，如果你们公司的业务是垂直产品的，可以用ABP没问题，因为它可以从模块到单体到微服务兼容，到微服务做到快速而高效的演化；如果你们公司的业务是项目型的交付，也可以重复利用ABP的模块化来降低开发的成本；如果你们公司是外包型的项目，面对交付各种各样，ABP一样可以通过排列组合来快速交付成果。我这里不是故意夸大，也不是为了宣传而宣传，而是真的觉得这玩意儿真的是很方便，谁用谁知道。

ABP难吗？

　　当然ABP入门容易，进阶困难，毕竟他是基础设施，里面有很深厚的技术深度，如果你只是停留在使用的角度，那么问题不大，可以很快入门，请相信我，对于有点.NET基础的人，可能一天就上手了，但是一旦遇到问题或者需要定制，那么你一定会遇到困难，这个时候你会迷失在碎片化的模块海洋，而且每个模块之间又有网状般的依赖关系，模块化是非常灵活的，一个解决方案你要分4层还是7层，甚至更多都是很有讲究的，因为你要深入理解DDD分层模型和业务需求。所以，当你需要深入学习的时候，你会觉得ABP不容易。

ABP存在的意义？

　　问这个问题就好比问我们有了Java，为什么还要有Spring。ABP存在真正的意义是让开发人员早点下班，做一个幸福的程序员。不要觉得这个要求很低，这非常困难。因为项目从开发到运维没有一个环节是容易的。项目初期，我们会为了进度加班加点，虽然累但不感觉疲惫，因为项目一直在推进。项目后期，你不断修改代码也可以接受，因为都是你自己写的代码，你知道怎么修改。项目运维阶段，你离职了，新人一边修改你的代码一边摇头骂娘，项目开始慢慢变质。随着一波又一波的新人不断折腾和累积屎山，你的项目遍体鳞伤、伤痕累累确又无法推倒重来，代码开始慢慢腐朽。

　　所有的这些都是因为团队缺乏规范，人员层次不齐，因为你没有一个行业最佳实践的地图。如果说ABP能帮助我们解决以上这些问题，那么它的价值自然不低。从事.NET开发人员如果您跳槽频繁的话，我相信你一定接手过很多遗留系统，很多系统从构建的第一天可能有了遗留系统的痕迹，所以如果我们要进行整体迁移，那就是一场噩梦，我干了10来年的.NET，真的还没见过成功的案例，要么团队能力不够，要么成本太高，要么风险太大……总之，一切问题都在第一天就定了基调。

　　除了项目管理和软件工程方面，在技术方面我们一样可以从开源的ABP身上学到不少经典代码、架构设计、测试规范、最佳实践。我举一个简单的多租户的例子，如果你有在用多租户，你一定能对它的多租户印象深刻，因为你好像感觉不到多租户的存在，也许这就是多租户的优雅之处。至于DDD就更不用说了，你跟着它的规范走一遍，你对DDD会有更加深入的了解，原来我们以前一直在用的贫血模式开发就觉得自己懂得了DDD。

　　ABP的意义真的不是三言两语能说的完的，毕竟它自己也不断与时俱进中，它本身从开源身上吸收的能量也在间接展示给我们看。我到现在都觉得自己不能精通ABP，因为它上手容易，精通真的不是那么容易，因为这意味着你曾经花费很大的时间从0到1重构了一次ABP，否则你怎么敢说自己精通ABP呢？

ABP会臃肿吗？

　　我经常听到有些人会说ABP很臃肿，我不知道他是指的哪一方面，如果只是泛泛而谈，我感觉是很不专业的，甚至我可以说对方根本没有深入研究过ABP。是Dll文件过多，还是启动很慢，还是吃内存，除非你能拿出证据来。

真正的臃肿是什么？

　　模块化是根据业务或者功能的一种拆分，目的是为了重用。拆分多了，你可能学习了会有点困难，因为那么多块块，如果你不够熟悉，身边没有一份说明书，你根本就无从下手。所以，那不是叫臃肿，我们有人会评价乐高很臃肿吗？相反，我们会觉得乐高很强大，很灵活，可以实现各种可能，除非你缺乏想象力，不要用自己想象力的缺乏来说乐高是臃肿的。

　　管理复杂系统必然要求我们对系统进行分类拆分，否则一块大单体岂不是更加臃肿？我理解的臃肿是，代码耦合度非常高，进行二次开发很困难，剪不断理还乱。另外开发完了，要进行运维修改很困难，甚至出现改到后面，改不动只能重新推倒重来，在旧业务online情况下，新框架要重新开发，变开飞机变换引擎，中间还要做数据库迁移，对于一般的小公司只是非常危险的，严重的会直接宣告项目死刑，因为改不动了，然后新进的人员也只想贴膏药，公司必然存在离职率高的问题。所以，我的结论是代码耦合高是臃肿，二开困难是臃肿，运维低效是臃肿。当然臃肿还有很多内涵，比如编译缓慢、部署麻烦、性能低下等等。

　　我像请教那些说ABP臃肿的人，你到底在说什么？模块化后，团队各自编译会缓慢吗？模块化后，模块可以单独部署也可以集成部署是臃肿吗？你使用ABP跑功能会很慢吗，所有的模块都在启动时候就预先加载到我们的内存里了，哪儿慢了？无非多耗费一点内存，多用一点空间换取的不是更快的性能是什么？

　　所以，请那些说ABP臃肿的人，不要泛泛而谈，请你在臃肿前面加个定语，然后用真实的案例来和大家交流。