>>关于MVC与三层架构

　　我认为MVC设计模式，关键在于构建Model，Model就是MVC模式的灵魂，他包含了三层架构里面的 “实体规范层”、“行为规则层”、“数据访问层”；控制器（Controller）用来收集View提供的用户数据，传递给Model，同时返回Model处理后的数据给View。Model的设计可以参考三层架构的设计方法，将实体、行为规则（业务逻辑）和数据访问分开，在数据访问上可以应用ORM框架。三层架构同样可以应用ORM框架。个人认为三层架构和MVC都是很好的设计方法，目的都是降低系统的耦合性，提高重用率，提高系统的可维护性，可以根据喜好进行选择。

　　如何在三层架构和mvc之间进行取舍呢？或者说它们就和我所理解的一样，根据喜好选择，没有实质的优劣。同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其他的两个层。在三层架构中没有定义Controller的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。

  　　三层架构是最基本的项目分层结果，而MVC则是三层架构的一个变体，MVC是一种好的开发模式。首先你要明白MVC分别代表的是什么意思：

　　M 即Model(模型层)，主要负责出来业务逻辑以及数据库的交互 
　　V 即View(视图层)，主要用于显示数据和提交数据 
　　C 即Controller(控制器)，主要是用作捕获请求并控制请求转发

三层：UI 界面层 BLL 业务逻辑层，DAL数据访问层，Model 实体层 
MVC中的的M 不是三层中的Model(实体层)，他其实包括三层中的 BLL，DAL,Model,这是非常要注意的，这也是他们之间的区别的关键所在。其优点如下： A、低耦合性； B、高重用性和可适用性； C、较低的生命周期成本；D、快速的部署；E、可维护性；F、有利于软件工程化管理。当然优点也有缺点，那就是内部结构复杂，不容易理解，文件数量大，管理难度自然也就大。

  

仔细研究了一下Microsoft ASP.NET MVC 1.0源代码， 
并在两个网站项目中进行了具体应用。大致的总体技术框架结构如下： 
基础结构： 全局接口、常量、公共工具类 
数据实体：定义数据操作实体，主要用于业务逻辑层与数据访问层交互 
业务模型层：定义具体业务需要的和View需要使用的模型类，用于业务逻辑层、View(视图层)、Controller(控制器)三方交互 
数据访问层：修改RepositoryFactory，直接延用大体框架 
业务逻辑层：提供业务处理服务，操作业务模型和数据实体

View(视图层)：主要用于显示数据和提交数据，引用业务模型层 
Controller(控制器)：主要是用作捕获请求并控制请求转发，调用业务逻辑层，引用业务模型层

个人感觉对于预期扩展性很强的系统，采用这种架构还不错

MVC设计模式…  

三层架构… 
他们细分之后得到的是：View(UI)、BIZ（BLL）、DAO（DAL）、Entity（Model）、Controller 
MVC把 BIZ（BLL）、DAO（DAL）、Model（Entity） 统一称之为 模型(MODEL)，得到：View、Controller、模型(MODEL) 
三层 在我使用中 暂未体会到控制器的存在，完全是：UI、DAO、BLL

他们相同的设计理念就是：把视图设计与数据持久化进行分离，从而降低耦合性，易于扩展，提高团队开发效率。