解
决了一些主要问题后,今天稍微有点空,于是给公司写了一些关于框架的想法,都是很幼稚的,主要是想锻炼一下写作能力,自乐一下。 如果读后感觉说的还凑
合,笑笑就可以了;如果感觉大错特错,也笑笑就好了;如果干脆觉得废话,请跳转到其他页面 继续浏览。当然,什么都好,别望了指
教。
常用体系结构
层次体系
层次体系就是利用分层的方式来处理复杂的功能,层次系统要求上层子系统可以使用下层子系统的功能,而下层子系统不能够使用上层子系统的功能。一般下层每
个程序接口执行当前的一个简单的功能,而上层通过调用不同的下层程序,并按不同的顺序来执行这些下层程序,层次体系就是以这种方式来完成多个复杂的业务功
能的。
客户机/服务器结构
客户机/服务器结构简称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的框架的解决方案的精华,选择当前最优的解决方案呢?回答当然是可以的。我们完全可以通过研究做一个针对现有市场上的框架解决方案的详细说明,说明其适用范围及优缺点。通过比较这些框架的解决方案,在框架的设计中,我们才有可能综合这些解决方案做出更优化的框架。
公司现在进行技术积累,在我的理解,不单纯的只是功能实现的重用,更多的应该是解决方案的积累,这样,公司的开发人员才能站在一个更高的高度思考问题。不论是否采用这种方式,但框架解决方案的积累,将会是公司积累的重要组成部分。
有很多方面没有展开说,只是为了想说明某一点,而只强调了这一点,而忽略了其他的方面;同时,考虑时间不长,也考虑的不是很周到,观点不一定正确,可以讨论。
Feedback
个人觉得体系架构从软件的视图来讲应该只有“层次体系”,是Tier,
而C/S与B/S应该算是Layer。
据我推测笔者所在的公司应该是做企业业务系统。做此类系统的公司多半都是在某一具体的业务领域。从技术的层面来讲,窃以为要完成两种框架(平台)的积累。
1 技术框架,包括使用什么样的平台,现在多半是NET与J2EE了。数据访问的策略,业务领域的组成,表现层控件积累,通用中间件(权限,日志)等等。因为此类公司所做的定制的系统的特点都差不多。没必要每做一个新的系统都要重新考虑这些问题。
2 业务平台框架,这就是一个企业软件开发公司的灵魂所在,也是核心竞争力。因为如果此平台搭建成功,做此领域的具体的应用系统会事半功倍,效率会极大提高。主要有几点前提:
1 积累,业务领域知识的积累。可能也是笔者所提到的解决方案的积累。因为没有这种积累,你就无法把握某业务领域的需求的共同点和不同点,无法把握需求的变化,而你建立的业务平台框架也将是无法扩展的。
2 意识,一般白手起家的业务软件开发公司,每天都在应付具体项目的开发与维护。这种情况很容易导致恶性循环。
每个项目都要从头再来----〉花大量的时间开发---〉效率低,项目难以维护---〉公司所有人都焦头烂额。
这种情况下公司的掌舵人就一定要有清醒的意识。必须要有欲造轮子,先在工具的意识。