企业应用框架的特点首先是，当应用框架确定之后，系统的整个构架，也就是主体结构就已经固定。因此框架的选取往往是方案选型的首要问题。

    其次，人们常常听信“组件式开发”的一面之词，认为系统搭建的过程类似于搭积木，好像是用胶水代码（glue code）拼合现成的组件或模块。其实采用框架开发时，系统的构建过程更类似于填空——系统骨架早已完成，开发者填写特定的代码，由系统来调用。《设计模式》中提到的“好莱坞原则（the Hollywood principle——Don't call us, we'll call you）”，非常符合我们谈的这种情况。很多框架还允许下游厂商开发系统插件（plug-ins），以满足特定需要——这是另一种形式的“填空”。

    另外，对于实现具体应用系统的二次开发者来说，不少任务都无需通过编程实现。比如要给一个业务模型增添一个新字段，或是要设置一种新的工作流程，这些工作都可以通过简单的图形用户界面（GUI）操作，或是修改部署描述符（DD），或是编写脚本来完成。也就是说，相当多（而不是全部）的开发任务是通过声明/配置的（declarative），而不是编程的（programmatic）的方式实现的。系统往往会在启动或运行时载入相关的配置，据此实现特定的功能。

    企业应用框架是菜场里的半成品。当我们面对要么自己下厨、要么去饭馆吃饭的选择时，我们往往会采取这种省时省力的折衷方案。但是选择之所以为选择，就因为其中肯定包含对收益和代价的权衡，都隐含着复杂的利弊关系（pros and cons）。下面我们也来检讨一下企业应用框架的情况：

    Pros：

    * 缩短开发周期

    毫无疑问，采用框架的开发，要比一切从头做起快速、高效得多。通过一般化（generalization）和重用（reuse）机制，框架能最大限度地加快一个特定应用系统的实现。

    * 客户化

    如上所述，基于框架的系统有很多功能通过配置而不是编程实现，这样也给用户带来了一定便利。比如，企业内部的IT人员经过一定培训，就能够自己完成一种新的工作流程的设置。这对于不断变化的业务需求是一个很理想的解决方案。

    * 不重新发明轮子

    框架对于大量典型场景给出了最优的实践。在具体开发时，与其无视前人的成果，重新构思答案，不如套用这些成熟、稳定的做法。这不仅能加快开发进度，更能够提升系统的质量和健壮性。

    * 可维护性/知识共享

    完全通过委托开发完成的系统很难由其他厂商维护。框架往往是多个企业、大量开发者实践的成果，因此能在一定程度上打破上述壁垒，增进系统的可维护性。当框架使用者形成社区之后，还能实现更高层次上的知识共享。

    Cons:

    * 太多

    半成品总有其代价。超市配好的一包菜里，老是又我们用不到的调料——但是我们却不得不为之付费。同样，为了达到一般性和普适性，框架总比紧凑、贴切的特定应用多出不少内容。二次开发完成后，企业获得的只是一种特定的实现，却要为所有的客户化可能性付费，为所有用不上的功能付费。这是一个相当让人尴尬的事实。

    * 太少

    框架总是一种限制。就像半成品菜限制了我们的烹调方法，框架也限制了我们实际应用的可能性。当框架本身设计的足够普适时，我们不太会感到类似的限制。但是，情况往往正好相反——面对一个足够特殊的需求，二次开发者总有一种冲破框架的渴望。最后的解决办法，往往是狡计、妥协和框架补丁的结合体。

    * 效率

    上面说过，基于框架的系统中，具体功能经常是通过配置实现的。与硬编码（hard-coded）的方式相比较，这虽然能提供很大的灵活性，但也往往牺牲了运行时的效率。

    * 锁定

    一个采用特定框架的系统几乎肯定被锁定在这个厂商的产品上。换言之，框架意味着all or nothing式的态度，很难调和两种不同的框架，各取所长，更难把应用系统从一个框架迁移到另一个——这往往要求系统的全部改写。

    * 学习曲线

    一种框架也就是一种方言。要精通特定框架的开发，你要熟悉其中的所有的用法、思路和弱点。对于开发者，这也意味着比较陡峭的学习曲线。

    上面谈到的种种弊端，还属于一般开发框架共有的缺陷。对于市面上流行的很多企业应用框架来说，更大的问题是框架产品自身的价格过高。我在别处也讲过，企业应用系统项目往往不能靠运行安装程序，再作简单的设置就完成，而是一个复杂、漫长、不断尝试/修改的过程，或者说，更近似于一种服务而不是简单的产品销售。但是框架厂商的产品（或者说是半成品）价格过高，经常就蚕食了整个系统的大部分开发预算，使方案总价偏重于框架本身而不是后期开发。对于需求不甚符合原有框架，需要大量开发的项目，或是需求本身不够清晰的项目，这都几乎肯定会导致整个项目的失败。

    软件工程宗师F. Brooks曾经表述过这样一个道理：没有银弹（No Silver Bullet/NSB）。那意思是说，没有一种万应药能够戏剧性地提升软件开发的效率和质量。最近的很多舆论好像是专门和这个经典论述抬杠，动不动就把一些特殊的解决方案奉为银弹。对于企业应用开发而言，基于框架的开发模式是多种选择中的一种。在不少情况下，这种选择是不错的，但同时应该留意随之而来的风险，更不该以为，选定了框架就一定能保证项目成功。

    很多企业应用项目的难点，在于客户自身缺乏规范的企业管理制度和合格的计算机应用水平。客户不具备成型的业务流程，也无法明晰表达需求，不知道怎样的应用形式对自身业务更合理：这种需求不清、或是需求剧烈变更的困境是困扰大量企业应用开发项目的症结。简言之，企业应用项目的成败经常是“业务”、“技术”、“管理”三种因素共同作用的结果，而单纯引入框架，只能解决部分“技术问题”。如果过于乐观地估计框架在其中的作用，甚至认为它能解决任何项目的任何问题，这对于本领域的各个环节（厂商、项目开发商、企业客户）都只能起到消极作用。

    我个人的建议是：在搭建企业应用系统时，针对应用情况不同、预算/时限不同、对系统指标要求不同，有多种替代方案可以从中选择。当需求明确、固定，又有现成产品完全满足需要时，或者当企业想要以极低预算消除某个业务瓶颈时，应该优先考虑现成产品；在需求明确、固定，但很难被现成产品完全覆盖时，可以选择应用框架，并由合格开发商完成实施；在需求不够明确，或者预感到需求会发生剧烈变更时，采用开发源码的应用框架，从而避免高昂的初期投资，并“软化”框架带来的种种限制，是另一种可供选择的思路。还是那个比方，一顿饭怎么吃，究竟是下馆子、买半成品或者全由自己动手，还要视具体情形而定——我也希望，每个企业都能吃上可口顺心的应用大餐。