层?为什么软件开发要分层

层?为什么软件开发要分层

一、事由
        最近一直在做项目的前期调研,大致的设计方案已经出来了,在与合作公司的另一个工程师做交流的时候,他突然冒了一句:本来简单的项目你们为什么还要用架构,还要分层开发!

        那个工程师以前做了很多年软件,VB、ASP的年代吧,现在主要转向做总工工作了,负责项目管理协调,我们公司是承接其中一部分软件项目,前些时候向他讲了一下我们开发的方式,主要是多层开发,团队合作的情况,基本没有讲通。这次拿了调研的结果他却说要是用ASP之类几天就做完了(实际项目规模编程需要6个人月时间),根本就不需要那么麻烦。一方面作为合作方他要贬低我们的工作方便商务谈判,另一方面确实有这方面的疑问,我想好好的分析一下他们的问题,谈谈自己的想法。 整理了他的问题:
         1.为什么要分层?
         2.如果分层是为了分工,那每个人分一个模块不是也很好分工么?
         3.分层如何提高工程效率,小项目是否还用分层?


二、经历
以下仅是我的个人意见,参考而已,我先介绍一下自己的经历:
        我最开始做的是单片机的开发,后来是WinCE的开发,基本都是一个人在做,和别人沟通的很少。程序就是一段一段的写,对数据库的操作很少,只有在WinCE上有一些SQLCE数据库的开发。
        后来参与团队项目的软件开发,Delphi程序,几个人一起,每个人分一个功能模块,项目负责人告诉我如何画界面、写程序、连接数据库、使用控件等等,掌握这些用了很长时间,很多经验除了别人传授更多的还需要自己去体会。
        再后来给一个项目作实施,那个项目是Java开发的,用的就是多层的开发方式,不仅将数据层封装了,同时对页面也进行了封装,那个时候比较可笑的是,仅作了半天的培训就开始进行软件实施,对程序的了解还没有客户知道的多就四处跑的给人家装程序,不过收获也蛮大,一个是熟悉了如何与客户进行沟通,还有就是对多层开发产生了浓厚的感兴趣。
       之后的一段时间里我开始自己写.Net的数据访问层架构,从网络上整理资料,现在这个架构已经应用了几个项目,应该是成功的,比自己预期的要好很多,也基本满足了网络上朋友们对数据访问层的要求。
        这个架构名称是:FrameCountry数据访问层架构,是在.Net平台下主要针对多层架构中数据访问层功能的,可以做到:
          1.不同数据库相同的开发、配置方式,尽可能的降低数据库操作差异;
          2.开发快速,对数据层的函数进行多样封装,开发人员主要精力放置在业务实现上,对数据库的数据操作变得很便捷;
          3.对程序的过程有详细的记录,记录操作数据的正确、异常、错误、事务信息;
有兴趣的朋友可以到下载最新的FrameCountry架构:
http://blog.csdn.net/lizheng82/archive/2007/06/18/1656140.aspx

       从我的经历来看,走了如下的四步:
       1.独自编程,简单软件
               项目规模很小,整个软件系统由自己完成,很少与合作者进行沟通;
       2.合作开发,非多层方式分工
               软件开发由多个人完成,每个人分配不同的功能模块进行开发;
       3.项目实施,接触多层方式
               开始了解多层软件开发的结构;
       4.应用多层开发
               完成数据访问层架构,并进行项目开发;
       基本上包含了几种开发的方式,也有些自己的体会。


三、架构理解
       言归正传,我的情况基本介绍了,现在开始说正题。我理解的多层架构是以四层为标准,分层如下:
       1.表示层
               实现用户操作界面,展示用户需要的数据;
       2.业务层
               完成业务流程,处理表示层提交的数据请求,使用数据访问层操作数据;
       3.数据访问层
               接收业务层的数据库操作申请,完成数据库操作,记录日志信息;
       4.数据库
               存储数据的关系型数据库;
       可能这样说比较抽象,我们可以举个例子,假设需要对数据库表Table进行修改操作,修改完数据后将修改人、修改时间、修改数值保存到数据库库中,看下图:


       现在再次以上图为例再说明各层应用描述:
       1.表示层(用户页面)
               在页面初始化时加载初始化数据,显示修改的编号、名称数值,用户修改数值后点击“修改”按钮,向业务层提交修改请求,并将修改的数值传递到业务层;
       2.业务层(实现业务流程)
               将用户界面传递需要修改的数值整理后向数据访问层提交修改申请,然后将修改时间,修改人的信息再次提交给数据访问层进行插入修改记录的操作;
       3.数据访问层
               业务层提出的操作数据库请求,组合成数据库识别的SQL语句,向数据库提交操作,并将结果反馈到业务层;
       4.数据库
               存储数据的关系型数据库;

四、问题
       说了那么多的话,现在开始回答那些疑问,三个问题就一起回答了。
        首先软件分层开发是否有必要!回答的是肯定的,就像问现在电脑办公是否有必要一样,趋势,别人都这么做了,也做得很好,那当然就有必要了。我认为多层开发的好处:
        1.方便团队分工
        以前的按功能模块一般是几个人将项目的功能模块一分,每个人从操作数据库、完成业务逻辑到实现界面都要独自完成,当然数据库的设计可以由一个人完成,这样的开发显然有弊病,首先每个开发人都需要掌握大部分技术,还要有很强的业务逻辑的理解能力,其次每个人的开发习惯都不同,形成的代码繁杂可读性差,最后后期的完善、维护都会造成麻烦。相信很多人都会理解这样的痛苦经历,多层开发就能解决上面的问题么?如果是一个合理的多层开发模式是完全可以解决的。
        将软件开发分层,其实可以简单的理解为工种分层、规范代码,基本可以将工作分为界面设计人员业务实现人员数据库设计人员界面设计人员的工作就是画程序界面然后将信息提交给业务层,不需要考虑业务层的逻辑关系,业务实现人员的工作是处理界面提交的数据请求完成逻辑流程,再结合数据访问层,不用考虑界面设计的样式、风格,也不用考虑数据库的格式,数据访问层一般是设计完善的架构系统,基本不需要人员工作,主要是屏蔽掉数据库间的差异,为业务层提供便捷的操作功能,数据库设计人员就是设计、规划数据库。很显然一个团队采用多层开发就可以合理的分配人员工作,将每个人放置到适合的岗位上,而主要的技术人员集中在关键部位的开发工作,重复简单的劳动,如画界面就可以安排给新手来完成。
        2.其他特点
                 还有以下的一些特点:
        规范代码:在开发过程中可以将每层的代码进行规范,固定开发语言的风格;
        忽略数据库差异:好的数据访问层可以将数据库的差异完全屏蔽,对开发人员只是做相同的数据操作工作,甚至可以快速进行数据库转换;
        基本上就想到这些,还有的就等日后慢慢整理了。
        现在回到那个问题,分层是否有必要,其实回答否定也可以,并且有理者也可以说出一大套理由来,所以还是看实际需要,再有上述为笔者的浅见,仅作参考。

转自:http://blog.csdn.net/lizheng82/article/details/1661809

展开阅读全文

没有更多推荐了,返回首页