应用程序框架设计之前言

要做一个应用程序框架的念头Bigtall在几年前就有了，因为在工作中发觉很多方面非常的不顺手，几乎每一个环节都存在这样或者那样的问题：

　　公司不同项目组做的设计是完全不同的风格，而且设计做不细，导致项目计划越来越流于形式 ，各层代码凌乱，从后台的java或者c#到前台的html，天马行空，随心所欲 数据库结构和文档不匹配，要不是莫名其妙的多、少字段，要不就是些莫名其妙的名字如果深入到设计方面，就会发现虽然做过很多的项目，但是几乎没有可以参考的成功案例，所有的设计哪怕是同类型项目，也几乎要重头开始；编码方面就更加麻烦了，我最深刻的印象就是从业以来我编制了无数的字符串处理函数，有c/c++版本的，有C#版本，有java版本的，还有delphi和早已忘记的vb，当然，更少不了时下流行的js了（这还是好的呢）。一旦到了项目规模较大的时候，我们甚至会在代码流程中迷路，不知道调用从哪里来，不知道逻辑要往哪里跳。

　　这么多的问题，是广大的处于CMM 1级的软件企业共同存在的问题，当然也会出现在那些CMM2345实际还是CMM1的软件企业中。加入管理手段（比如真正去实施CMM规范）可以解决大部分的问题，准确地说是可以解决几乎所有的管理问题并缓解大部分的技术问题，但是解决不了所有的问题。

　　以前bigtall在的公司曾经出现过这种论调“技术是不重要的，市场和管理才是最重要的”，最后公司走入了低谷，好不容易聚集的人才也散了。别人的教训就是自己的经验，bigtall后来进行深刻的反思，认为这里有一个“度”的问题，我们先看两个极端“只有市场和管理但是没有技术”“只有技术没有市场和管理”的后果，一个是“守不住”，一个是“推不了”。其实两者是相辅相成的，技术可以把市场的门槛推高，市场和管理可以让技术更顺利地发展。所以一个公司没有“最好”的技术，只有“最适合”的技术。一个公司的技术目标应该也只应该是“不断降低公司的成本”。

　　最明显的就是项目系统设计的重用问题，无论你是CMM多少级，如果没有一个统一的软件架构，重用就会打折扣甚至根本就无法重用。就像南方人北方人沟通要用普通话，今人和古人沟通就必须用相同的文字（顺便鄙视并可怜一下朝鲜、韩国和越南）一样，前后的项目要能够沟通交流，他们就需要一个相同的结构。所以“程序框架”就是公司项目之间的“普通话”，也是项目内部的“润滑剂”。

　　这里要明确一下“程序框架（Framework）”和“软件架构（Architecture）”之间的区别，简单地说，程序框架是一个可以实际应用的代码集合，而软件架构可以看作是一种抽象的设计。另外，两者的关注面也不一样，程序框架热衷于解决实际运行过程中的问题，甚至会提供工具包或者辅助模块（比如权限系统、日志系统等），而软件架构则集中精力在各个部分（模块、组件等）之间的关系。两者其实是关于同一个事情的不同层次的东西。

　　我们可以来看一下如果存在程序框架会让文章开头的几个问题解决多少：

　　如果有程序框架，因为项目的WBS几乎是一致的，所以上一个项目的项目计划可以直接拿过来使用，而且经过几个项目之后，这个项目计划的模板会越来越细，越来越实用。 设计过程中，除了需求之外，概要设计、详细设计的重用性会很高。

　　因为结构一致，代码混乱性会降低到可以接受的程度，而且可以重用上一个项目的大部分代码。而且逻辑清晰，使得代码相对较小，不容易在代码中迷失。因为代码逻辑简单有序，所以测试起来会很容易。

　　降低管理成本，除了项目计划之外，测试计划，QA计划等等都可以重用，如果用CMM规范，项目评审的速度和质量都会有提高。

　　要做一个应用程序框架并不是一件容易的事情，一是这方面发展很快，而且水平相对较高，如果没有独到的解决方案，可能自己的框架一出来就过时了。二是应用程序框架涉及的方面较多，考虑清楚并不是一件容易的事情。三则是开发一个应用程序框架需要耗费大量的时间，也就是意味着公司需要花费（你的工资×开发时间+其他）这么多的金钱。

　　对于小公司来说，除非有着清醒的认识，否则开发自己的应用程序框架可能是自寻死路。bigtall建议小公司如果.net开发，则直接用Petshop4的框架，如果java开发，则直接使用appfuse进行开发，如果想要一个新的语言，则直接用Ruby On Rails开发吧。对于php没有建议，不太熟。

　　现在如果要开发一个应用程序框架，至少需要满足如下的几个条件：

分层（废话）
易于测试
易于扩展，并跟现有的其他系统进行无缝整合。一般要具有AOP、IOC、DI能力。
易于部署
具有权限，用户管理能力
有组织架构、工作流、规则引擎支持
有页面流转，状态管理能力
MOF或者MDA能力
SOA能力
　　界面技术的抽象能力（如WebForm，HTML，Ajax，Xml，Rich Web等）
bigtall的应用程序框架设计系列文章准备从简单开始，一步一步记录并呈现给大家bigtall开发框架的整个过程。文章列表如下：

　　多层应用之间的数据传递
　　多层架构已经成为了标准，但是数据在穿越各个层次的时候，它的形态有什么变化和规律呢？

　　界面层的分析和抽象
　　界面层承载了应用程序所有的可视部分，究竟里边还有多少我们需要关注但是却忽略了的事实？
　　MOF/MDA的支持和程序的设计规范
　　如果人在根本上是不可靠的，那么就尽可能不用人去做。但是到达这一步，我们还需要告诉机器一些什么东西？
工具！我的工具！
bigtall设计的小工具要做一个应用程序框架的念头Bigtall在几年前就有了，因为在工作中发觉很多方面非常的不顺手，几乎每一个环节都存在这样或者那样的问题：

　　公司不同项目组做的设计是完全不同的风格，而且设计做不细，导致项目计划越来越流于形式 ，各层代码凌乱，从后台的java或者c#到前台的html，天马行空，随心所欲 数据库结构和文档不匹配，要不是莫名其妙的多、少字段，要不就是些莫名其妙的名字如果深入到设计方面，就会发现虽然做过很多的项目，但是几乎没有可以参考的成功案例，所有的设计哪怕是同类型项目，也几乎要重头开始；编码方面就更加麻烦了，我最深刻的印象就是从业以来我编制了无数的字符串处理函数，有c/c++版本的，有C#版本，有java版本的，还有delphi和早已忘记的vb，当然，更少不了时下流行的js了（这还是好的呢）。一旦到了项目规模较大的时候，我们甚至会在代码流程中迷路，不知道调用从哪里来，不知道逻辑要往哪里跳。

　　这么多的问题，是广大的处于CMM 1级的软件企业共同存在的问题，当然也会出现在那些CMM2345实际还是CMM1的软件企业中。加入管理手段（比如真正去实施CMM规范）可以解决大部分的问题，准确地说是可以解决几乎所有的管理问题并缓解大部分的技术问题，但是解决不了所有的问题。

　　以前bigtall在的公司曾经出现过这种论调“技术是不重要的，市场和管理才是最重要的”，最后公司走入了低谷，好不容易聚集的人才也散了。别人的教训就是自己的经验，bigtall后来进行深刻的反思，认为这里有一个“度”的问题，我们先看两个极端“只有市场和管理但是没有技术”“只有技术没有市场和管理”的后果，一个是“守不住”，一个是“推不了”。其实两者是相辅相成的，技术可以把市场的门槛推高，市场和管理可以让技术更顺利地发展。所以一个公司没有“最好”的技术，只有“最适合”的技术。一个公司的技术目标应该也只应该是“不断降低公司的成本”。

　　最明显的就是项目系统设计的重用问题，无论你是CMM多少级，如果没有一个统一的软件架构，重用就会打折扣甚至根本就无法重用。就像南方人北方人沟通要用普通话，今人和古人沟通就必须用相同的文字（顺便鄙视并可怜一下朝鲜、韩国和越南）一样，前后的项目要能够沟通交流，他们就需要一个相同的结构。所以“程序框架”就是公司项目之间的“普通话”，也是项目内部的“润滑剂”。

　　这里要明确一下“程序框架（Framework）”和“软件架构（Architecture）”之间的区别，简单地说，程序框架是一个可以实际应用的代码集合，而软件架构可以看作是一种抽象的设计。另外，两者的关注面也不一样，程序框架热衷于解决实际运行过程中的问题，甚至会提供工具包或者辅助模块（比如权限系统、日志系统等），而软件架构则集中精力在各个部分（模块、组件等）之间的关系。两者其实是关于同一个事情的不同层次的东西。

　　我们可以来看一下如果存在程序框架会让文章开头的几个问题解决多少：

　　如果有程序框架，因为项目的WBS几乎是一致的，所以上一个项目的项目计划可以直接拿过来使用，而且经过几个项目之后，这个项目计划的模板会越来越细，越来越实用。 设计过程中，除了需求之外，概要设计、详细设计的重用性会很高。

　　因为结构一致，代码混乱性会降低到可以接受的程度，而且可以重用上一个项目的大部分代码。而且逻辑清晰，使得代码相对较小，不容易在代码中迷失。因为代码逻辑简单有序，所以测试起来会很容易。

　　降低管理成本，除了项目计划之外，测试计划，QA计划等等都可以重用，如果用CMM规范，项目评审的速度和质量都会有提高。

　　要做一个应用程序框架并不是一件容易的事情，一是这方面发展很快，而且水平相对较高，如果没有独到的解决方案，可能自己的框架一出来就过时了。二是应用程序框架涉及的方面较多，考虑清楚并不是一件容易的事情。三则是开发一个应用程序框架需要耗费大量的时间，也就是意味着公司需要花费（你的工资×开发时间+其他）这么多的金钱。

　　对于小公司来说，除非有着清醒的认识，否则开发自己的应用程序框架可能是自寻死路。bigtall建议小公司如果.net开发，则直接用Petshop4的框架，如果java开发，则直接使用appfuse进行开发，如果想要一个新的语言，则直接用Ruby On Rails开发吧。对于php没有建议，不太熟。

　　现在如果要开发一个应用程序框架，至少需要满足如下的几个条件：

分层（废话）
易于测试
易于扩展，并跟现有的其他系统进行无缝整合。一般要具有AOP、IOC、DI能力。
易于部署
具有权限，用户管理能力
有组织架构、工作流、规则引擎支持
有页面流转，状态管理能力
MOF或者MDA能力
SOA能力
　　界面技术的抽象能力（如WebForm，HTML，Ajax，Xml，Rich Web等）
bigtall的应用程序框架设计系列文章准备从简单开始，一步一步记录并呈现给大家bigtall开发框架的整个过程。文章列表如下：

　　多层应用之间的数据传递
　　多层架构已经成为了标准，但是数据在穿越各个层次的时候，它的形态有什么变化和规律呢？

　　界面层的分析和抽象
　　界面层承载了应用程序所有的可视部分，究竟里边还有多少我们需要关注但是却忽略了的事实？
　　MOF/MDA的支持和程序的设计规范
　　如果人在根本上是不可靠的，那么就尽可能不用人去做。但是到达这一步，我们还需要告诉机器一些什么东西？
工具！我的工具！
bigtall设计的小工具 

http://dotnet.csdn.net/page/c710fe28-a52c-40d0-ad0e-3f5c8a67ac58