第一段，一张脸，笑对千万人，拖放，所见即所得。
互联网：
刚刚毕业时，公司要做电子商务和社区混合体，若干人等请求一个web站点的典型互联网应用。一个站点，满足众多人，个性化要求也不外乎换换皮肤。直接拖放控件加一点点自定义控件足以满足。完全符合众多n日成教材开发模式。得以让刚毕业的我没有丝毫不适感。
企业内部：
后面转到企业IT部门做内部应用开发——SCM，那更好了，自己处于销售端，让供应商用什么就是什么，完全不提供个性化要求（汗），所以还是控件拖放。这时候不同的是，由于企业输入信息量大，对一些输入界面要求比较高，还好基本上网上搜搜，自己改改还是能满足要求。
总结：开发速度快，成本低（主要指的是开发人员技能需求低）
第二段，求包养。
再然后
销售方式：公司提供标准版B/S套件，在此基础上，修修补补满足客户的要求，然后整套部署到客户的服务器上。这时候还是应用为主，客户提出的多是业务方面的新需求，界面需求停留在报告的美观上（行业性质决定）。
开发方式：这时候采取的策略是一个客户一个版本，所以不管你需求和标准版的相差在那里，方正针对你的更改在代码上和其他人没有任何交集。这时候还是拖放加买商业web控件套件。好在此时国内此应用软件供应商不多，本公司早早在占有率达90%以上，本公司的标准就是标准。后台设计时已经考虑到不同业务，更多业务封装到数据库里，实施工程师基本就是折腾数据，开发人员折腾存储过程。前端设计少有更改，只是添加新页面，新功能，一般用模板页加自定义控件。不过此时已经要开始写js组件了，因为觉得买的控件满足不了需求或者影响了关键页面的性能。
总结：处于通过代码copy来达到应用复用阶段，代码工啊代码工，累啊累。在各种条件具备或者是说是无奈的情况下，不失为一种比较安全的开发模式。此时前端，后台，数据库技能已经提升了要求。
再再然后
销售方式：电子政务，满中国跑，忙着给政府做企业应用。有一条电子商务标准放那里，前端是一个血拼点。
开发方式：提供标准版，在此基准上修改。一客户，一版本。但是已经进化到有自己的一套可视化业务设计工具。业务，流程可视化组装，可视化修改外观，开发人员可新建，扩展组件。实施人员可以非常快的做出一个项目。
总结：还是属于通过copy代码得到复用的方式。技术实力非常不错，开发人员呈金字塔状。理想中的开发模式。
题外：为什么技术这么强的公司，收入不是很好呢？服务所面向的行业才是王道。用奔驰拉客和用背篓运白粉，赚的不是一个数量级。
第三段，嫁，陪，小三，onenight
没有最后
销售模式：1，我运营，用户注册购买应用；2，卖代码，客户自运营；3，我运营，你嵌入，大家分成。客户遍布全球。
开发方式：
1， 全局xml配置所有界面组件内容，全局xsl文件配置组件解析，全局css文件负责样式，后台xml和xsl合体解析出html文本输出到浏览器。按客户配置xml文件css文件，xsl文件，这些客户文件可继承，覆盖全局配置。
2， 2，先定义一些基本组件的描叙约定，然后客户xml文件按约定描叙界面所有元素，后台解析xml文件并生产一些列标准的asp.net 控件对象组装到WebPage对象里，客户Css文件负责样式。没了全局配置文件，没了继承，覆盖。后台是标准解析流程。
总结：
两种的前端都脱离了对cs这种需要编译才能运行的机制。用描述语言去描叙不同客户的需求。绕口的话，请想象下标准asp.net webform或者 mvc开发模式，每个页面有个后台类的概念，每个客户一个类或者每个客户一个controller等等，通过反射创建客户的服务类。
更要命的是一个类或controller对应一个***.aspx文件。
第1种源自于asp年代，第2种最近才开始做迁移。第1种至少给了继承和覆盖的概念来实现代码的复用，原生的xml和xls模式，灵活性太强了。自然，技能要求是比较高的，UI设计师基本不能和程序员配合。完全没所见即所得和拖放的方便性。第二种收回xls的灵活性，把解析工作交给了asp.net，且不用postback机制。没了xls，不影响灵活性，灵活全交给了css。现在开发起来，比原来效率快多了。后面可以进一步走的是，可视化客户xml文件的生产：组件化各种约定，拖放组件到设计界面，最终得到一份客户xml文件和css文件，或者是二者的合体文件。