框架
应用程序框架设计之前言
要做一个应用程序框架的念头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的支持和程序的设计规范
如果人在根本上是不可靠的，那么就尽可能不用人去做。但是到达这一步，我们还需要告诉机器一些什么东西？
来自:http://www.cnblogs.com/BigTall/archive/2007/12/06/985101.html
CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。
CMM是是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。CMM分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。
CMM是由美国卡内基梅隆大学软件工程研究所1987年研制成功的，是目前国际上最流行最实用的软件生产过程标准和软件企业成熟度等级认证标准。目前，我国已有软件企业通过了CMM标准认证 。
WBS：项目管理里的工作分解结构。
面向服务架构SOA（Service-Oriented Architecture）是一种架构模型和一套设计方法学，其目的是最大限度地重用应用程序中立型的服务以提高IT适应性和效率。它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。SOA的关键是“服务”的概念，W3C将服务定义为：“服务提供者完成一组工作，为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态改变，或者双方都产生变化”。
