.NET 框架设计（理解）

1、框架的通用作用及层面：

     软件开发要满足用户的功能性需求，只有在满足了功能性需求的前提下，非功能性需求才算有价值的。可以归纳出软件开发的两大需求：功能性需求，非功能性需求。前者优先级高。

     功能性需求可以用各种方式实现，在满足功能性需求后，需要完成非功能性需求，非功能性需求形态各异：安全、性能、稳定性、易维护、易伸缩。在满足了功能性需求后，这些将变成重点考虑的范围。
框架的主要作用就是让我们更好的实现非功能性的需求，因为非功能性需求直接影响这功能性需求的使用。良好的用户体验、良好的视觉效果，这些都是现代软件所必须的。

2、 框架的生命周期：

        现代应用软件的需求发生翻天覆地的变化，从功能性需求到非功能性需求都在飞快地发展和创新，框架所在的位置就必然要求他能够快速满足这些不断变化的上层需求。能够快熟的支撑上层需求变化是考验框架的整体指标之一。

       非功能性需求的一个特点就是不变性。这些需求可能在任何一个软件系统中都会需要。但在功能性需求是各不相同的。每个软件系统都有各自的业务需求，尽管大体相似，但在业务细节的处理上还有很大差别。

       所以非功能性需求是完全可以在多个系统之间复用，即非功能性需求可以复用，那么用来支撑的框架也就可以复用了。

       框架在其生命周期中，为了满足各种需求，需要不断的维护。在多个系统中复用框架，必然会出现很多定制化需求，所以框架在其生命周期中需要经常修改，这样才能保持框架的重要价值。因此框架并不是固定不变的。

3、框架设计：

       框架设计有着复杂的过程，每一步都需要严格把关。这是因为框架设计在系统架构中举足轻重，他的修改对系统的冲击很大，会牵一发而动全身，所以对框架设计的要求要高出一般业务功能，只有这样才能保证框架的最终质量。

      3.1 确定问题域和识别变化点、

              首先需要确定问题域，问题域也就是你将要用框架来解决的问题范围，有了范围之后我们才可以针对每个点进行详细的分析。例如通信框架，首要是确定业务范围，他允许哪些类型的消息通过该框架，在脑海中需要有一个大致的范围。

              Client<=>通信框架<=>Servie。

        确定了大概的问题域之后，就可以进一步分析他的变化点。变化点的整理何以让我们更细致的了解架构，这对后面的架构选择很重要，因为架构模型是由架构模式驱动出来的，正所谓模式驱动模型，模型驱动设计。模式是对莫一类固定问题的求解方式和方法，是经验的总结。确定了问题域之后，我们就可以选择相应的模式来驱动出符合当前问题域的框架架构。

               <=================================变化点 ==============================>                                                   

Client<=传入/接受消息=> <= 通信接口<=>安全<=>压缩<=>通信框架<=>压缩<=>安全<=>通信端口=><=传入/接受消息=>Service

   3.2 选择合适的架构模式、配置变化数据、可视化管理

        选择架构模式的前提是你已经确定了问题域并且识别出了大部分的变化点，这样我们才能准确的选择架构模式。通常一种模式对应一种问题的解决方法，在必要情况下需要组合多个模式来搭建一个符合当前问题域的模式。（如果你识别出来的变化点够详细，可以考虑是否需要组合多个模式来完成一个架构模式）

      通过上面的问题域和变化点，可以大概得知将使用如下几种模式：

          1、通信框架：管道模式

           2、消息：契约式设计

           3、通信端口：异步消息+事件驱动

           4、安全：链接式编程

           5、压缩：：ICO注入第三方压缩方法

  设计好架构之后，就需要将变化点配置起来，以便在需要的时候动态的切换变化点。配置的方式基本上有两种，一种是在本地通过静态文件的方式，另一种是通过远程服务动态配置的方式。两种方式对应不同的场景。静态配置通常用在无需及时更新的时候，而远程动态配置是需要在运行时动态的调用随时会变化的配置，如促销价格及折扣率。

     框架设计中另一个很重要的部分就是可视化。大部分框架都会忽略可视化部分的设计，其实是不正确的。一个完整的框架必须配备可视化工具来帮助我们方便的使用框架和管理框架。（例：上述框架中添加可视化工具跟踪和查看框架中的消息，便于我们在测试的时候查看消息的状态，修改消息的内容）

    作为一个完善的框架，不仅需要在运行时稳定，而且也要保证该框架的可测试性。若能做到在测试时，框架内部是透明的，那么将大大提高框架的受欢迎度。

      4 、框架设计核心三元素：模式、配置和工具

          4.1 框架模式：

              框架模式是一套针对框架设计而言的解决方法，不同的模式解决不同的问题域。你可以使用单一的模式解决一个单一的问题，也可以使用一整套模式来解决一个复杂的问题。

                不同的模式最终会驱动出不同的模型出来，而模型就是框架的最终架构。有了模式之后，我们所关心的就是该模式如何用代码实现。熟练掌握这些模式能让你在框架设计上得心应手，因为每种框架都有一套与之对应的模式，只要熟练这一套模式、模型及代码实现，你很快就会判断出该问题域所使用的模式。

           4.2 框架配置：

                 框架的设计必然少不了对一些数据和逻辑的配置。配置的设计也是相当复杂的，设计配置的存放位置、读取方式、配置信息的生成方式，这些都将决定框架内部如何与这些配置信息协调工作。

                大部分框架在设计配置部分的时实现方式都比较单一，缺乏灵活性，在框架读取配置信息的时候也比较生硬，不够平滑。所以配置部分的设计将是框架整体设计的重要元素之一。

          4.3 框架工具：

                框架的可视化部分非常重要，尤其是在现代大型企业级应用架构中，任何一个地方出现问题都会引起一些连锁反应，这个时候我们急需使用工具来定位到问题，或者起码要帮助我们定位到问题。

               工具需要在一下几个方面提供对框架使用的支持：

                      1. 开发时：可视化编程已经不是新概念了。要在开发是带有部分可视化自动完成的功能，最后是集成在Visual Studio 中的插件，这取决于框架的使用方式。

                       2. 编译时：企业级分布式框架需要在很多环境中运行，在测试阶段需要在测试环境中运行，在发布到生产线之后就需要在真实的环境中运行，不同的环境，需要配置不同的环境信息，测试环境可能不存在负载均衡，而在真是环境中会有集群，这个时候就需要我们在使用框架编译时能够生成一些环境变量信息。

                       3.运行时：运行时的工作责任重大，日志、监管、调试等功能都需要框架提供，有了这些功能，我们对框架使用才会更有信心。

 

总结：在一般的框架设计中，配置、工具一般不会被提及，但在企业级框架中，这两项就显得极为重要，是衡量框架是否健全的重要标准。

模式是骨架，配置是变化点，工具是辅助管理。从框架的架构到变化的配置再到框架的使用工具，这才是一条正确的框架设计指导路线。

（源自《.NET 框架设计》）