从零开始编写本身的C#框架（28）——建模、架构与框架

　　文章写到这里，我一直在犹豫是继续写针对中小型框架的设计仍是写些框架设计上的进阶方面的内容？对于中小型系统来讲，只要将前面的内容进行一下细化，写上二三十章具体开发上的细节，来讲明这个通用框架怎么开发的就已彻底足够了，由于对于中小型系统来讲，并非很复杂，简单的了解三层架构就已经够用了，而使用太多的设计反而有点罗嗦，由于基本上没有什么人会为中小型系统花费太多的设计工做。而对于设计大型平台的框架设计，又深深感到本身的积累还远远不够，写出来怕会误导你们。但不换个思惟来说述也很难说清框架的设计思想，别人拿到一个框架源码后，也很难让人能清晰的理解这个框架究竟是什么东东，怎么去改造它。因此只能抱着和你们共同窗习的心态，来抛砖引玉，但愿能更好的总结一下本身的学习成果，固然有些观点并不必定是正确的，也但愿你们能直接拍砖指出来。

 

前言

　　不少朋友看到标题可能会很奇怪，为何弄一个开发框架首先要作的是建模？建模就能作一个框架出来吗？直接的人可能会说，这个2B，设计一个开发框架讲解的核心应该是三层、五层架构，每一个层应该有什么用处，他们之间该如何解耦如何协做调用......

　　若是之前有人告诉我设计一个框架这样作的话，我也会以为弄一个开发框架搞得这么复杂作什么，直接弄几个层和工具类出来，而后写一些常见功能不就好了。

　　实际上写本系列以来，理论部分一直在琢磨怎么才能用更通俗易懂的方式讲解出来，像前面章节同样直接从三层架构去讲，只能很简单的说明他们之间的关系，但为何设计出来的是这样的框架而不是那样的？前面章节所作出来的框架能直接用在网站后端管理上，但若是做为电商平台、OA、CRM、供应链......等软件框架时行不行？会不会存在问题？要如何去改善？若是开发的框架用于电商平台，当访问流量增大，想要增长服务器作分布式、负载均衡进行数据分流时，是在现有框架上改造令它支持仍是设计一个新的架构呢？要如何改造或如何设计？设计好的架构支持什么样的业务？如何让需求提供者（未技术人员）能更早的参与到架构设计进来？如何尽早发现系统框架的瓶颈？怎么从设计层就能解决众多的问题？如何让新入职人员快速理解并掌握整个框架知识，快速加入开发的队列中？若是避免核心技术只把握在某一个或几我的员手中，当这些人中有人离职后其余人员没法快速接手的问题？设计的系统可否根据业务拆分为一个个独立的模块，让测试人员提早加入到项目中，提高项目的质量？拆分的模块如何统一块儿来？......越想问题就越多，怎么去描述都讲不到点上。

　　通过知识的不断积累，慢慢意识到一直以来使用的都是面向过程的方法来分析需求，在作项目或设计架构时，都是为了功能而设计，为了设计而设计，并不知道其因此然。若是想作出的框架对于项目来讲能作到适用，恰好合适，那就须要真正的去分析需求，根据用户实际的需求以及发展方向来设计架构，它是面向对象的，使用用例或领域来驱动设计，为特定需求而定制设计出来的系统，而不是作出来的架构功能过多或未达到设计要求，或者用上一段时间后整个架构甚至数据表都得推倒重来。

　　固然上面所说的都是理想状态下设计出来的系统，而实际工做中你们开发中的架构或平台，面对每一次大版本的更新都是欲仙欲死的，呵呵......不少时候都得大动手术，进行大改造。

 

UML、架构与框架的关系

　　度娘上说：

　　Unified Modeling Language (UML)又称统一建模语言或标准建模语言，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的全部阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。

　　软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的链接则明确和相对细致地描述组件之间的通信。在实现阶段，这些抽象组件被细化为实际的组件，好比具体某个类或者对象。在面向对象领域中，组件之间的链接一般用接口来实现。

　　对于框架来讲，就是已作好的钢筋混凝土结构建筑物，里面能够建各个功能的停车场、商场、酒店、饭店、商住房......

 

　　架构对于框架来讲，它就是绘出好的建筑图纸，它描述建筑物的外部形状、内部布置、结构构造、内外装修、材料作法以及设备、施工等各类图样。而UML就是在这些图纸上所绘制的各类形状的图形（符号）。

 

　　有不少朋友会说，我不用UML、不懂架构同样开发出一套套不一样功能的框架，干码要学这么多，能作出来不就好了呗。的确是这样的，对于功能简单、中小型的项目，或本身已作过不少相似框架的架构来讲，直接编码是一个不错的选择。而对于一个大型的，或复杂程度很高的，或高风险的，或你彻底不熟悉的领域的项目来讲，开发前先作好相关的设计工做，能帮助你下降项目失败的风险。

　　框架不是万能的，不是什么系统都适用，就算是通用的管理权限框架，也有它的局限性。就好比本系列前面章节所开源的框架代码，权限管理模块相对来讲比较强大，但也存在着各类弊端。好比说将它用于一个简单的企业Web站，它属于过渡设计了，多了不少没必要要的功能，让开发变得复杂；而对于一个企业管理软件来讲，它的权限粒度还不够细，好比须要实现对于不一样角色的人须要展现不一样的内容列表就没有实现到；底层应用的ORM框架也限制了只能使用MsSql数据库；UI层执行效率慢......因此咱们在设计时，要有针对具体的需求来设计不一样的架构，合适才是最好的，而不是不管什么时候都追求最强大的。

　　架构比如一个软件的骨架，不一样的设计适合不同的领域，就好像小鸟的骨架适合飞翔，豹子的骨架适合奔跑同样，若是设计好的架构要强硬的去改变它适合其余领域，不是不能够，这会增长很大的难度，就好像想让小鸟变得像豹子一个能够奔跑，又能够飞翔同样。

　　在实际的开发过程当中，不少项目不是你一我的就能单独完成的，在团队协做开发中，如何能让你们都明白你的意图，能配合你将项目开发出来，就须要借助相关的工具（UML或其余建模语言），简单的绘制出业务用例、各类视图和模型，来帮助你们理解与配合。

　　对于大中小型不一样的项目来讲，花费在架构设计上的时间都是不一样的，据巴利·玻姆（Barry W. Boehm——软件工程估算模型COCOMO模型之父、软件过程螺旋式模型之父）所计算，对于小项目只需投入5%左右的时间；大中型项目须要点总时间的33%~37%的时间；而超大型项目，则需投入40%的时间。

 

建模应用在实际开发中所带来的好处

　　一、让非技术人员提早理解所开发出来的系统能处理的业务内容

　　对于非技术人员来讲，他们看不懂各类代码，而业务用例则可让他们提早理解将要实现的功能是什么，是否是他们想要的内容。

　　二、让测试人员能提早参与到项目中

　　当模型建立完成并讨论经过后，相关的测试人员就能够开始编写测试用例，以及相关的自动化测试接口，让开发人员提交了解测试的内容与思路，能够提早参与到测试当中，并为测试提供更多的意见与角度，提高程序的质量，另外当程序完成开发后，也能立刻运行自动化测试代码，加快测试进度。

　　三、让开发人员对所要开发的项目有更深刻的了解

　　对于大多项目来讲，除了架构的设计者这外，其余开发人员对于软件框架了解只是只知其一;不知其二，只熟悉本身那一块的工做，对其余模块了解并不太深。这就形成不少沟通上的障碍，就算让他负责更多的功能模块开发，也只是让他了解太更多一点而已，当软件架构的功能限制对业务扩展的支持，须要改造软件架构时，几乎没几个开发人员敢去随便修改底层框架代码，这主要缘由就是对本身架构并不了解，怕改动后影响其余模块的正常运行。而有成熟的架构文档，这将帮助开发人员了解软件框架的运行机制，各模块、组件以前的关系，让他们有能力有条件有信心去对软件框架进行改造。

　　四、让新加入的开发人员更容易了解项目

　　一位新成员加入开发团队时，最头痛的就是怎么快速接手项目，投入到开发中去，而有了相关的架构模型，，开发人员能够简单的经过查看架构模型和对应的文档，快速的了解整个开发框架和其技术要点。

　　还有其余不少好处这里就不一一诉说了。

 

 版权声明：

　　本文由AllEmpty原创并发布于博客园，欢迎转载，未经本人赞成必须保留此段声明，且在文章页面明显位置给出原文连接，不然保留追究法律责任的权利。若有问题，能够经过1654937@qq.com 联系我，很是感谢。

 

　　发表本编内容，主要是为了和你们共同窗习共同进步，有兴趣的朋友能够加加Q群：327360708 ，你们一块儿探讨。

　　在佛山工做的朋友也能够加入：佛山IT朋友群 263767221，你们能够共享资源共同进步，有空你们能够约出来认识一下，交流一下技术，哈哈

 

　　更多内容，敬请观注博客：http://www.cnblogs.com/EmptyFS/