框架的建议

解决了一些主要问题后，今天稍微有点空，于是给公司写了一些关于框架的想法，都是很幼稚的，主要是想锻炼一下写作能力，自乐一下。 如果读后感觉说的还凑合，笑笑就可以了；如果感觉大错特错，也笑笑就好了；如果干脆觉得废话，请跳转到其他页面 继续浏览。当然，什么都好，别望了指教。
常用体系结构
层次体系
层次体系就是利用分层的方式来处理复杂的功能，层次系统要求上层子系统可以使用下层子系统的功能，而下层子系统不能够使用上层子系统的功能。一般下层每个程序接口执行当前的一个简单的功能，而上层通过调用不同的下层程序，并按不同的顺序来执行这些下层程序，层次体系就是以这种方式来完成多个复杂的业务功能的。
客户机/服务器结构
客户机/服务器结构简称C/S结构或称两层结构。
客户/服务器应用模式的特点是大都基于“肥客户机”结构下的两层结构应用软件。客户端软件一般由应用程序及相应的数据库连接程序组成。服务器端软件一般是某种数据库系统。
三层次客户机/服务器结构和浏览器/服务器结构的数据库服务器管理端由于客户端连接数少，也常采用C/S结构。
浏览器/服务器结构
“浏览器/服务器”结构是当前非常流行的客户机/服务器结构，简称B/S结构。
这种结构最大的优点是：客户机统一采用浏览器，这不仅让用户使用方便，而且使得客户机不存在及安装维护的问题。
三层次客户机/服务器结构
三层次客户机/服务器结构是在常规客户机/服务器结构上提出的，系统在客户机和数据库服务器间添加一个应用服务器。
框架扩展
（1）所支持系统体系结构的扩展
以上介绍的体系结构，都是较为流行的，应用的范围比较广，我们的框架必须要支持不同的系统结构，以满足不同系统的要求，这里既包括业务的要求，也包括项目成本的要求以及其他。
当前公司所使用的框架可以支持三层客户机/服务器结构项目的开发，如果用来开发同是Windows应用并且要求快速的客户机/服务器结构的项目，框架将会变得臃肿不堪，那么框架的优势不能完全体现，而且还会造成部署和维护的困难。
开发框架的目的是提高项目的开发效率，所以为了适应不同体系结构和进度要求的项目，需要有相对应的框架支持开发。比如要求快速并且可以选取客户端/服务器体系结构相对小型的项目，成本低，而且系统使用范围也只是局域网，那么此系统的体系结构可以采用支持客户机/服务器的框架；如果项目属于分布式的应用，使用三层次客户机/服务器体系结构，那么可以使用支持三层次客户机/服务器结构的框架等。
根据现有常用的体系结构，至少有对应的三套框架：针对客户机/服务器结构的框架、三层次客户机/服务器结构的框架以及浏览器/服务器结构的框架。（并不是说要有三套独立的框架代码，三套框架共有的组件可以复用，比如数据访问层，比如通用接口等）
（2）技术的扩展
简单一点，就拿层层之间通信来说吧。现在的框架是使用Remoting技术实现客户端与服务端之间的通信，我们肯定Remoting技术的优点的同时，也要看清Remoting技术的缺点。 鉴于WebService的跨平台的优点，实现与不同平台系统之间的交互，完全可以将框架之间的通信技术通过WebService实现，使框架不仅可以满足了局域网的快速通信的要求（Remoting）,也可以满足跨平台的通信的要求(WebService)。
现在.Net 3.0提供的四个功能组件中，其中一个新的功能组是Windows Communication Foundation（WCF），有了WCF，开发人员不必再像从前一样，处理每一类通信都要使用到不同的应用程序编程接口技术，使得通信应用变得简单。因此，我们的框架也应该实现基于Windows Communication Foundation技术的通信，而不单纯的使用Remoting。
技术的扩展，不仅包括上面所说的，以前我们没有使用过的技术，或者是微软最新提供了新技术，我们都可以考虑是否用于我们的框架，只要这样的技术有优势，并符合我们业务的要求。
建议
（1）       我们所做的工作不能以.Net或者Java平台来区分，不能说使用.Net，就拒绝Java。简单一点，它们都只是工具，我们应该更多的去关注在它们之上并且是想通的思想。
举个例子，企业级应用的开发首选是J2EE，针对J2EE的表示层、逻辑层和数据持久层都有很多免费并且应用成熟的框架，而现在基于.Net的还没有这样具有影响力、成熟的框架。我们不是说要用J2EE的框架，至少我们应该有意识的去了解它们，了解它们的工作原理，了解它们的设计思想，了解它们的应用范围，了解它们的优缺点等，然后将这些总结运用到.Net平台。有巨人的肩膀给你支撑，难道就因为它不是黄皮肤，我们就强烈地拒绝？
（2） 不论是在.Net平台还是Java平台，我们所要做的不仅仅只是局限于将现在的框架在不同的平台上实现（相当于将框架从.Net平台转换为Java平台），这样的工作没有太大的意义，因为我们所做的只是在功能实现上进行修修补补，框架始终停留在初始水平，进步可能只局限于技术的实现或者算法的优化，这样的做法将会限制框架的发展。极端一点，就像一个人的思想认识停留在远古，显然无法满足社会进步的要求。
对框架的具体实现，使用相同的技术，不同的人会有不同的实现方式，这个并不是框架优劣的主要决定因素。一个框架的好和坏，在于每层以及层和层之间的设计，这个设计包括：（注：这只是我个人的想法）：
首先，是所采用的解决方案，它是框架的灵魂，是思想，所有的实现都是解决方案的外在体现，就像建筑的架构（当然，这也许和平台所提供的技术有关系）；
然后，在解决方案确定后，就是根据平台所提供的技术，确定适合的技术方案，就像各部分采用何种材料；
最后，才是详细设计和实现，用采用的技术实现功能，提供可用于项目开发的框架。
如果要做新的框架，所作的工作只是将现在的框架进行照搬，进一步完善，再来个优化，这样的框架和原来的框架有什么区别，那新的框架还有什么用处？原有框架的解决方案可行，但不代表是最优的，我们是否可以通过汲取现有.Net平台的框架或者J2EE的框架的解决方案的精华，选择当前最优的解决方案呢？回答当然是可以的。我们完全可以通过研究做一个针对现有市场上的框架解决方案的详细说明，说明其适用范围及优缺点。通过比较这些框架的解决方案，在框架的设计中，我们才有可能综合这些解决方案做出更优化的框架。
公司现在进行技术积累，在我的理解，不单纯的只是功能实现的重用，更多的应该是解决方案的积累，这样，公司的开发人员才能站在一个更高的高度思考问题。不论是否采用这种方式，但框架解决方案的积累，将会是公司积累的重要组成部分。
有很多方面没有展开说，只是为了想说明某一点，而只强调了这一点，而忽略了其他的方面；同时，考虑时间不长，也考虑的不是很周到，观点不一定正确，可以讨论。