MVC 即 Model View Controller 。mvc是一种很好的设计模式的综合应用。其中
M 即Model（模型层），主要负责处理业务逻辑以及与数据库的交互。
V 即View（视图层），主要用于显示数据和提交数据。
C 即Controller（控制器），主要用于接受请求并控制请求转发。
三层架构，是最基本的项目分层结果。秉承“高内聚，低耦合”的思想，将整个业务应用划分为：UI层（表示层）、BLL（业务逻辑层）、DAL层（数据访问层）。系统的主要功能和业务逻辑在BLL层进行处理。
UI：表示层，也叫做用户界面层，用来接受用户的请求，以及数据返回。。可以是WEB、也可以是WinForm。
BLL：业务逻辑层，主要负责对数据层的操作，对数据业务逻辑的处理。
DAL：数据访问层，直接操作数据库，包括增、删、改、查、备份、还原等操作。
从二者的区别，我没有在网上找到一个定论，主要观点以下有几个：
① MVC是一种复合设计模式，而三层是一个软件架构。
软件架构是用接口来实现的，而设计模式则是一种设计思想、设计理念的升华，也可以算做一种解决方案。一个系统一般只有一个软件架构，而可以有多个设计模式，因为设计模式是可以复用的。
② 在三层架构中没有定义Controller的概念，而MVC中也没有将业务的逻辑访问看成两个层。当然了。在三层中也提到了Model，但是三层架构中Model(Entry)的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。
③三层结构模式又可归于部署模式，MVC可归于表示模式。
④三层架构划分为：View(UI)、BIZ（BLL）、ADO（DAL）、Entity（Model）、Controller。而MVC把 BIZ（BLL）、ADO（DAL）、Model（Entity） 统一称之为 模型(MODEL)，得到：View、Controller、模型(MODEL) 三层。
我认为，二者并不是互斥的，相反，MVC和多层应用软件结构有着异曲同工之妙，而且可以相互结合进行开发。MVC中的每一个环节都可以采用多层应用软件结构进行设计。而多层应用软件中的每一层又可以采取MVC来进行设计。所以说可以是：M层对应于BLL和DAL。V对应于UI，而C则对应于层与层之间的联系。也可以M对应于DAL，C对应于BLL，而V仍然对应于UI。
再次谈起三层架构来，初识三层时的那种向往，那种青涩，已经不见了踪影，取而代之的是对分层的感慨。
分层，三层也好，七层也罢，都是将页面显示、业务逻辑控制、数据访问进行解耦。还有MVC和设计模式也是这样。只分UI,BLL,DAL这三层，只是实现了基本的解耦，但是耦合性还是很高的，尤其是对于中型及以上的系统来说，简单的三层并不能满足其需求。DAL提取出DBHelper，BLL中提取出Facade层，还有各层之间其实都应该加上接口。这样系统的灵活性才会大大提高。
对于B层的划分，有人说按数据表走，一个表一个类；有人说按窗体走，一个窗体一个类(PS:我这里是重构，有原系统做参考，如果是开发一个新系统，则没有这种说法)；有人说按用例走，一个用例一个类。合作开发完以后，我好好分析了一下这三者。第一种方法，B层的类会相对少一些，维护工作会比较轻松，不过假如增加一个功能，那么就得相应的修改B层的类，不满足开闭原则。第二种方法，局限性更大。只要修改窗体，就得修改类。这样给人的感觉，B层依赖于UI层。但是分层应该是上层依赖于下层。第三种方法，满足开闭原则，添加功能，直接添加一个类即可。但是不足的是B层中类太多了。分析之后。我觉得应该改善第三种方法，在B层包中，为每个表添加一个子包，然后对应B层的操作放到对应子包中。这样就不会太乱了。添加功能时，直接在对应的子包中添加类。一个用例一个类。满足了开闭原则和单一职责原则。
对于Facade层如何划分，暂时没有确定的想法。有2种观点：一是将有关系的类，相近的类放到一个外观类。另一种观点按UI层来划分。不过感觉第一种观点稍微科学一点。暂时没有更好的想法。
在个人版和合作版开发完后，感觉接口挺重要的，开发接口可以大大增加系统的灵活性。而且，每一层只要针对于接口进行编程即可。不用考虑下一层的具体实现。下一层如何更改都无关紧要，只要接口不变，那么系统运行无阻碍。在开发前期，先开发接口，这样上层接口在编程时，调用下层会很容易，且不易出错。调试的时候也很方便。
