关于MVC的业务层
最近项目想采用MVC，但实在搞不懂业务层是放在那里。
都说Controller是来转发请求的，也就是说不参与实际的业务处理，而Model才是实际处理业务的地方

但我看过相关的资料后，发现Model一般只有数据实体，就是get、set这种，然后带一些数据注解来验证，还是没看到业务逻辑的处理放在哪里。难道MVC的model有两种，一种是类似于三层的数据模型，还有一种是处理业务逻辑的？实在没搞懂。

最好有什么比较好的案例可以参考一下，谢谢。
------解决方案--------------------
MVC和你的DAL、BLL神马的不冲突
------解决方案--------------------
Model的确是实际处理业务。实体model一般在dll里面这个不冲突的。mvc主要的就是view 和 controller 路由需要使用 model你可以自定义成其他文件后缀都可以
------解决方案--------------------
还是那问题“到底是那个老兄告诉你什么mvc就不能3层，用了3层就不能mvc滴”

既然根本没人这么说过，为啥你们就一定认为mvc就不能做业务层了
------解决方案--------------------
mvc就是把三层的视图层给一拆三，你说业务层该放哪里？
------解决方案--------------------
我不太想去纠结什么asp.net mvc，我给你从MVVM来说一下吧。

在MVVM模型中，传统的MVP中的P被弱化了（实际上大多数人还是手写大量的事件处理代码，但是微软的MVVM想提醒人们弱化这个部分）。于是重点就是M和V。

但是M有两种，一种是实体主管跨层通讯时使用，一种是前端应用程序中的为了V而一一对应地设计出来的M——叫做VM(ViewModel)——主管为V绑定数据使用。

最后，不管什么MVC、MVP、MVVM，都是前端应用程序编程模式。这并不妨碍你的独立的服务器端程序有一个独立的BLL层代码。（可惜，许多asp.net程序员分不清自己的程序是前端程序还是服务器程序，一律混在一起）。

因此你的MVVM（或者说你的MVC）总可能有一个“业务层”，主管后端业务层的客户端代理对象。例如我会写一个叫做GateWay的类型统一处理它，或者如果你使用WCF之类的那么就是服务器端发布的每一个服务（例如.vc文件）在客户端上自动产生的那个代理层类型。

为什么asp.net程序员往往混乱业务层？因为许多人是图asp.net门槛最低而使用它的，只知道写一个类似于本地读取数据库的小程序，而没有在一个有着“前端-服务器端”的大项目中做过。实际上如果你是这种单进程的小程序，你的“业务逻辑层”应该是一个与MVC都没有关系的层，然后主要在你的C以及VM层中调用，或者只在VM层中调用。因此MVC任何一层都不是业务逻辑（客户端）层。