ui 不是3层里面的 

3层是业务架构

bll dal  model

web 的结构是5层

在bll上加一个ui 在model 下加一个持久

@小眼睛老鼠: Model贯穿于多个层之间，不包含在三层中吧。

http://baike.baidu.com/view/687468.htm

我查了下 也是的 估计是我以前一直记忆错了

@小眼睛老鼠: 哦，对于一般的小型项目，分层就是浪费。

@幻天芒: 哈哈 我觉得不是啊 

你要是熟练的话 分层花不了什么时间的

只有在框架不完整的情况下，需要关注细节的情况系分层才会显得冗余

@小眼睛老鼠: 对于小项目而言，分层代表着提高复杂度和增加代码量。几w行的项目，我一般都采用BLL+DAL混杂在一起的用法。

@幻天芒: 怎么说呢

分层是会带来开发上的复杂度和工作量

但是界限分明，能够将功能划分成更小的模块 

能够正真做到对开发者的要求降低（一个能够掌握全局结构的人，带着几个会写代码的，不需要所有人都知道全局结构）

以及日后维护性的提高

而且还有一点就是，项目中影响项目进度的很多的时候都不是开发成本

而是解决问题的成本，解决问题比开发需要消耗的时间大很多

但是层次结构清晰的程序显然更有利于查错（因为可以将程序划分的若干个块，便于问题的划分）

还有第二点就是 项目的生命力

很大程度在于程序是否具备可扩展能力

所以在我来看

一段程序结构清晰可扩展的简单的程序 和一段逻辑复杂的程序功能强大的程序

我倾向于前者 因为后者维护意义不大

@小眼睛老鼠: 可能你一开始就进的大公司。当你一个人1~2个月一个项目的时候，你就分层是多么悲催。当然我没有说分层不好的意思。对于大中型或者长期维护的项目来说，分层还是是十分有必要的。呵呵~

@幻天芒: 你搞错了，我一开始进的就是小公司，从一个人干起，到带领一个队伍，一直将时间和精力花费在设计和重构上（一开始手写3层代码，后来代码生成器，然后自己构建orm框架，由一开始一个分页就要弄死人，到后面只要继承一下就可以搞定所有的事情），当然一开始很痛苦，各种不适应，但是当你突破了一个界限之后（即能够通过一些技术手段将业务和技术分离，将统一的东西融入项目，学会在别人的框架上去构建程序，而不是从头开始写程序），到那时你会发现一开始比较复杂的3层，它带来的效率损失会因为，使用框架 和 设计上的复用而弥补（而且弥补的多的多，一开始做的好慢慢的你会发现越写越轻松，相反会越写越复杂）

@幻天芒: 还有一点要和你说下，对于项目来说当然速度和质量是最重要的，但是对于个人来说，学习是最重要的，有时候想使用一个新框架，但是新框架会带来各种问题，这个时候会出现抉择，是用还是不用，当然用的话会遇到非常大的困难，会面临压力，但是如果学会了后，就会有极大的成长。这里需要权衡自己的近期目标和远期目标，并将2个融合，这样才能做到工作学习2不误。

我觉得你应该好好的考虑下这些问题。不要单纯的从完成任务的角度去考虑这些问题，当有一天你能够突破一个界限之后，到那个时候你会获得更大的成长。

@小眼睛老鼠: 受教了，感谢。有时候分层不那么明确也是情非得已，部分公司的现状是，在短时间交付（质量，维护性不在考虑之类），业务的定制性导致通用的东西较少，这时候确实没法分得那么细。

现在的公司设计时间约等于编码时间，这时候就会有明确的分层架构了。