mvc的控制器为什么要分离视图和业务逻辑层？

mvc的控制器为什么要分离视图和业务逻辑层？

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

三层:UI 界面层 BLL 业务逻辑层，DAL数据访问层，Model 实体层
MVC中的的M 不是三层中的Model(实体层)，他其实包括三层中的 BLL,DAL,Model

首先N层结构可以将低软件的复杂度，提高其可维护性。

一般来说，层次之间是向下依赖的，下层代码未确定其接口（契约）前，上层代码是无法开发的，下层代码接口（契约）的变化将使上层的代码一起变化。

简单的说界面层依赖业务逻辑层；业务逻辑层依赖数据访问层

MVC模式是一种复合设计模式，MVC中的三个事物之间并不存在明显的层次结构，没有明显的向下依赖关系，相反的，View和Model往往是比较独立的，而Control是连接两者的桥梁，他们更像是横向的切分。

所以MVC中每个块都是可以独立测试的，而三层结构中，上层模块的运行测试势必要提供下层代码或者提供相同接口的桩。相对来说，MVC复杂得多，但是结构更清晰，耦合性更低。

另外，MVC中每一块内部特别是Model内部经常被设计为多层的。

一个良好的MVC模式构建的结构中，Control是核心，小且稳定，可扩展，但基本上可以简单配置不需要任何代码就可以运行。

而View则可能是一套或多种可选择的视图引擎，决定了软件展示给用于的界面，使用时的主要工作量在于扩展点以及根据需要而数量不同的视图模板。

Model则是业务提供者，决定了软件提供的功能，其内部可能是一些普通的类或者是实现了某些接口的类，由于业务的不同而不同，对于复杂的软件可能会分成很多层，如业务逻辑层、业务提供层、系统提供层、数据提供层、数据访问层等。追问mvc是横向的？小弟不是很理解：
三层结构确实是两层间相互依赖的，但是修改时貌似就已经解耦了--界面问题只改界面，逻辑问题只改逻辑，数据访问问题只改数据访问。但是处理一个业务模块时，确实有可能出现您说的多层都需要测试的情况。
mvc貌似也相互依赖啊？view依赖controler,controler依赖model。
感觉controler加进来就为调用业务逻辑层，逻辑层得出结果给controler,controler传参数给view。但是这样到底有什么好处呢？追答就比如说ASP.NET MVC吧，实际上它实现的就是三层架构中的界面层

controler加进来就为调用业务逻辑层，逻辑层得出结果给controler,controler传参数给view
==
控制器接受用户的输入并调用模型和视图去完成用户的需求。所以无论你在界面中做什么操作，比如单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。

mvc貌似也相互依赖啊？view依赖controler,controler依赖model。
==
“模型”不依赖“视图”和“控制器”，模型不关心它会被如何显示或是如何被操作。
控制器是可以不在ASP.NET进程中使用的，单元测试很方便