MVC到底怎么分层

出处：http://blog.sina.com.cn/s/blog_604527460100kuyn.html

MVC，在程序中一个永远离不开的话题。由于层次架构，在程序设计之初就必须形成，对程序整体走向与把握起着十分重要的作用。然而总让人困惑的是：MVC到底怎么分层！

那么就先对我自己认为比较理想的分层方法说说吧，如果大家有什么意见，欢迎多多指点。

 

View层/UI层（界面层）：

1. 界面中所有控件必要的格式判断。

2. 搜集界面中所有控件信息，并将之传入Controller/BLL层。（最重要的功能）

 

Controller/BLL层（业务逻辑层）：

1. 接收界面层的数据。

2. 数据类型格式的转换。

3. 处理业务逻辑。如决定如何调用以及组织Model/DAL层的方法（增删改查），决定实例化的对象（角色），权限的判断控制等。（最重要的功能）。

 

Model/DAL层（数据访问层）：

1. 提供对数据库基本操作访问的方法或接口（增删改查）。

2. 提供对特定类的具有针对性的方法或接口。

3. 对数据库访问类的组织和管理。

 

对于我们来说，争议最大的地方便是BLL层。其实都知道是处理业务逻辑的，可是，逻辑？到底是什么逻辑呢？逻辑判断到底放在哪？

BLL层的一个设计准则是：对上层提供最为简单最为明确最为实用的方法。换句话说，就是提供的方法尽量少的且功能强大。如果你提供的方法越多，就意味着越复杂，上层用起来就越繁琐，对上层人员十分不便。如果方法越少，那么这个BLL就越有通用性，也就是说可复用的程度就大增，对于界面层的结构布局也起到统一的作用。

还有很多人，BLL层就直接返回DAL层的方法，如 return 类名.方法()。这样一来BLL层名存实亡，存在的价值就根本没有了（完全可以去掉），这样形成的架构，就看似头重脚轻，架构的稳定性、灵活性、拓展性十分差。其实我想说，这是完全错误的做法。MVC架构其实就好比一个金字塔，如下图：





对于我们现在做的Web开发模式的教务系统，我认为BLL层在设计上就有很大的问题，采用的便是头重脚轻的错误做法，而且web开发的界面层本来就相对于B/S的复杂，在给加上全部复杂的判断，任务可谓是相当的重。这样界面层出错的几率也随之增加。

BLL层其实应该是需要重构的，但是现在既然都这样开始动工了，也没时间再改来改去的，这次就这样好了，下次再多多注意吧。