层？为什么软件开发要分层
一、事由
最近一直在做项目的前期调研，大致的设计方案已经出来了，在与合作公司的另一个工程师做交流的时候，他突然冒了一句：本来简单的项目你们为什么还要用架构，还要分层开发！
那个工程师以前做了很多年软件，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.其他特点
还有以下的一些特点：
规范代码：在开发过程中可以将每层的代码进行规范，固定开发语言的风格；
忽略数据库差异：好的数据访问层可以将数据库的差异完全屏蔽，对开发人员只是做相同的数据操作工作，甚至可以快速进行数据库转换；
基本上就想到这些，还有的就等日后慢慢整理了。
现在回到那个问题，分层是否有必要，其实回答否定也可以，并且有理者也可以说出一大套理由来，所以还是看实际需要，再有上述为笔者的浅见，仅作参考。
