构建NetCore应用框架之实战篇（二）：BitAdminCore框架定位及架构

本篇承接上篇内容，如果你不小心点击进来，建议重新从第一篇开始完整阅读。

构建NetCore应用框架之实战篇索引

一、BitAdminCore框架简介

---

从前篇论述我们知道，我们接下来将要去做一个管理系统的框架。

BitAdminCore框架是一个定位于后台管理系统的快速开发框架。项目源码地址：https://github.com/chenyinxin/cookiecutter-bitadmin-core

后续篇章将逐步分解整个框架的完成过程。

二、框架解决什么问题

---

上篇已经提出了框架需要解决的几大问题，在这里一一作答：

我们的框架面向对象是谁？

答：管理应用系统的初级或中级开发人员。

他们平时都会遇到什么共通的问题？

答：快速上线。各种技术问题。

我们的框架需要解决他们哪些问题？是否所有问题都需要解决？

答：不能解决所有问题。事实上，框架并不能解决开发人员的问题，解决的是项目的问题，不管开发框架怎么先进，开发人员每天工作时间都不会变，工作过程遇到的问题数量也不会变，变的是相同时间内能完成的功能数。框架解决的是不同项目中，开发人员遇到的相同问题，把它们形成一套解决方案，固化代码，在下个项目时，它便不再是问题。

例如：A项目需要登录功能，于是程序员用2天开发了一个登录功能，还有一堆bug。当A项目开发完成后，我们发现B项目也会用到登录功能，整一个叫框架的东西，里面只有登录功能。当B项目来的时候，我们只需要将框架代码应用进去，登录功能便已经完成。此过程可能只需要5分钟。请问，这有没有解决程序员的问题？答案是没有，项目经理也知道程序员只需要5分钟，不会给他分配2天时间。

我们的框架需要包含哪些模块？为什么需要包含这些模块？

答：上述示例已经明确说明，一个框架需要包含的模块。框架需要哪些模块，是由未来的项目决定的，也即公司的业务战略决定，而非架构师。架构师只是把它落实而已。

我们提供什么样的开发模式，可以让开发人员更快速解决问题？

答：代码可读性。重复代码不需要开发。

在实际生产中遇到的问题，架构师在理想状态下设计的要多得多，面对众多的初级开发人员，代码可读性应该作为架构的第一选项，A人员开发的代码如何在B那里快速看得懂。

所以，作者个人反对各种使用接口、调用来调用去的方式，以展示个人的技术有多高超。

我们提倡直接、暴力。让代码架构看起来像初级工程师写的直接简单。

三、BitAdminCore定位

---

BitAdminCore定位原理上述已经阐述。BitAdminCore起码于作者工作经历，十几年不变的管理软件开发，以前也接触使用过不同框架，各有优劣。以前net、后来使用java、再后来netcore出来之后，果断转移到netcore。

选择netcore是对比选择的结果，C#的语言优势这个不用细说，前些年，由于android以及开源趋势没有跟上，net处于下风，但时间推到2018年，随着微软战略的云化以及开源化，还有安卓进入中晚年，单从技术层面netcore对比java已经占上风，这个人使用两种语言对比后认为，但是生态仍需时日。

作为应用开发人员，省时省力才是关键，管它什么语言。所以，坚定不移选择走netcore路线，包括公司及个人影响下的团队。

BitAdminCore定位于”为个人周边团队提供管理类项目快速开发能力支撑“，同时，适应时代发展，进行开源分享。

四、BitAdminCore架构原则

---

个人观点，软件行业是全世界最先实现共产主义的行业。

事实上，我们每天都在免费使用别人花了很大力气和成本开发出来的软件，这在传统生产行业是不可能的事。而且免费趋势越来越火。

在这样的社会条件下，BitAdminCore框架跟随大队，一是开源，二是利用开源。目标是项目开发最优的解决方案。

五、BitAdminCore架构

---

基于以上提出的一些原则：可读性优先、开源、快速开发的特点。我们进一步设计我们的框架。

首先是技术选择和评判：

1、基于通用技术框架包括：html5，css3，js，Jquery3，boostrap3

解释：a、只要是个写程序的，以上技术不可能不会。b、boostrap4变动太大，个人同事都熟悉boostrap3，短期内学习成本高。

2、抛弃netcore默认的PageModel实现模式，选择静态页面+webapi模式。理由：一是太复杂需要学习成本，二是是可移植性差，三是保持所有开发模式一致。

解释：a、前端技术均需要掌握并能达到开发目的，再花成本学习一个更小众的应用没必要。b、框架如果想移植到java，包含太多net特性。c、开发web、app、weixin等客户端保持相同的开发模式，减少学习成本。

3、NetCore.All这个就不解释了，自己去看引用包结构。

4、sqlserver，理由：之前部分代码是sqlserver实现，直接迁移过去，最近也在考虑mysql版本。

解释：除非客户有特殊要求，不管语言或数据库，都是开发的人说了算，既然熟哪个就用哪个。

5、ef与sql混合。理由：长期实践结果，判断依据可读性优先。

解释：在长期的开发工作中，发现ef对于复杂的查询实现，可读性非常差，调试极度麻烦。我们把单表操作用ef，而多表操作全部使用sql实现。

6、AdminLTE后端管理界面模板。理由：随便选一个。

以上就是整个框架的底层技术选择。

本篇介绍到此，框架功能规划原则上面已经提及，下一篇继续介绍框架的功能规划选择。