框架，这个词现在都用烂掉了。.NET框架，JEE框架，....我想说的是，咱们这些应用软件开发公司如何架构自己的框架。主要还是谈谈.NET路线的吧。
总体来说，两种类型：
1 平台型：本身基于.NET上做了很多工作，上面的开发者只能基于这一套来搞，相当于再完一次整的包装，这也是通常意义上的“框架”所指。比如很多数据访问层框架，NHibernate,Entity Framework.
2 库型：只是将一些常用的功能封装成一些公共的类库，供开发者使用。开发者跳舞还是在.NET平台上跳，需要播放音乐的时候，说一声“Music”即可调用音响团队的功能即可，大家处于同一个级别。
两种类型各有优劣。
平台型的优点在于公司NB的架构师一方面结合公司的业务将.NET这一块浓缩一下，同时，会扩展一些方便功能的功能，将一些最佳实践注入该框架中，新手在上面跳舞，bug少，效率高；是优点，也是缺点，你限制了我的舞台范围，那我就只能跳这几只舞，如果要跳其他类型的舞蹈，发现这个时候的代价就大大的增加了，出现了“80%的问题20%的精力解决了，剩下的20%的问题确需要80%的精力来解决”。这就是公共平台（.NET）和专项平台（你从.NET中延伸出来的框架）的优劣所在。此外，有的开发者对这种平台型的框架有抵触，因为你这个框架缺乏通用性，天天在你这个公司用这个框架干活是很舒服，但是，哪天离开这个公司，没有这个框架，还真不适应了。
库型的框架不给你这么多条条框框，只是给你很多轮子，你不用重复造。你跳还是在.NET平台上跳，限制少。发挥的空间大，公共库中没有提供的，那就自己去“写意”。这意味着出错的概率也大了，不同的人会写出很多参差不齐的代码，有的很拙劣，有的很优秀。但是，这种做法，没有失去通用性，到其他行业或者做其他类型项目，基于.NET再发挥就是啦。从我见到的情况来看，开发者相对喜欢这个，基于人家的框架，有点受制于人的感觉；库型的呢，我爱用不用。
公司的利益和个人的成长有时候确实是矛盾的。老板关注产品质量，关注生产效率，而且软件行业人员流动大，人员素质形形色色（对自己的代码的质量追求、工作心态很不一样），特别希望有一些框架能够帮助实现高质量的产品，高效率的生产；开发者喜欢自己这也搞搞，那也学学，哪怕付出一些代价，都要有所收获。
我觉得一个公司的开发框架可以从以下三个角度入手：
1 完整的业务规则，大家都要遵守。这里的业务规则，与代码无关。更多的是指公司的研发流程体系，比如需求充分沟通制度，设计充分演练制度，代码自测制度，代码审查制度等。
2 最佳实践的综合。不用企图做一个平台型的框架，那样成本太高，风险大。相对来说，库型的框架更加合适，但是为了防止参差不齐的代码，建议多进行最佳实践的传播。最佳实践不可能在方方面面顾及到，但是，可在一些经常碰到的选择上提供必要的指导；至于一些节骨眼的问题，提请架构师组讨论裁定即可。
3 提供一个代码生成器。对于大多数代码来说，基本上是重复的，提供代码生成器，减少重复代码的编写，同时，在需求变更或者设计变更的同时，提供快速的更改，对于大多数MIS类系统而言，这点尤其重要。