请问 Asp.net MVC里的Models可以用三层里的DAL和BLL层取代吗?

[guolucky2003]

习惯了用DAL和BLL层,总觉得Asp.net MVC里的Models很像,请问在实际开发中,大家一般是怎样使用的呢?

[wlccomeon]

我们现在BLL和DAL都在用呢，Models基本上不用了。。。

[以专业开发人员为伍]

一个简单的asp.net网站，实际上跟单机小程序基本上相似，它不是访问一个独立的“业务服务器”的，而是访问本地的业务程序集的。 实际上，这时候不太需要区分什么“三层”。如果你没有刻意去区分三层的话，就不需要勉强。 MVC的model应该是围绕着View而设计的Model，用来简化前端数据绑定，尽量让前端少写代码。因此许多数据，不一定跟后台数据库相对应，许多数据都是在内存中计算所需要的。设计mvc的model，不应该围绕“三层”的业务逻辑层来设计，而是应该调用业务逻辑层（也就是说，目的是千方百计完成前端用户需求，弱化后端的影响）。 从大的方面说，有些人满脑子只有数据库表，根本不懂前端设计。眼中没有千变万化的前端设计，那么自然，他的所有“前端设计”都是围绕着底层来拼凑一点千篇一律的UI。那么这时候就更没有必要勉强将mvc跟三层分开。 这里边的关键，不在于技术。你用什么工具或者框架已经没有多大意义，邯郸学步的责任不在于人家的城市、而在于学步的人本身。

[以专业开发人员为伍]

假设说你有60种数据实体，你有200个不同的界面，而且一年之内可能因为需求进化而增加（包括原来页面的大改）100个页面，那么你可能就总共有250个前端model，而还是保留原来60个三层里的model。这里的关系，就是“自由度”的问题。如果一个人能思想有自由度，他就能想接受着250个model，从而就能接受需求千变万化的结论；反之他就对提出需求变动的人表示各种不理解、或者不创新。

[圣光麦造]

mvc的model 作用 定义数据结构 数据库沟通 数据验证 定义逻辑规则 model和controller关系是提供给数据和验证给controller使用 有些view映射的是model定义的结构类型 如果说是使用 dal bll 就仁者见仁了 看自身项目架构 如果结构脱离了soc 那还是mvc吗

[凤凰涅檠]

Asp.net MVC里的Models 你觉得应该是什么。。。

[wjq]

MVC只是UI框架，代替的只是三层框架中的UI层，那些滥用MVC的把业务逻辑写到Controllor里的已经算是理解歪了，lz居然想拿M替代DAL和BLL，是我见过对MVC最歪的理解了~

[guolucky2003]

引用 4 楼 sp1234 的回复:

MVC的model应该是围绕着View而设计的Model，用来简化前端数据绑定，尽量让前端少写代码。因此许多数据，不一定跟后台数据库相对应，许多数据都是在内存中计算所需要的。

你这句写得很好，我之前也有想过，是将EF写在DAL里，而将MVC里的model里我放自定义的类，因为View界面需要的数据不一定就是DAL里的数据，所以需要自定义类，还有表单的规则，都可以在Model里实现。

[wjq]

引用 11 楼 wyumening 的回复:

[quote=引用 7 楼 wjq 的回复:] MVC只是UI框架，代替的只是三层框架中的UI层，那些滥用MVC的把业务逻辑写到Controllor里的已经算是理解歪了，lz居然想拿M替代DAL和BLL，是我见过对MVC最歪的理解了~

那你的意思是说mvc只是ui框架，mvc中的model只是起到一个实体的作用，不能替代dll，bll? 也就是说有必要的时候再建立dll，bll层？也就是说mvc和三层在一个项目中可以共存，是这样子吗？[/quote]基本上就是这个意思，MVC里 的M是为了V服务的；MVC+三层的理想状态下，我说要把项目换成WinFrom的，那你需要改动的也只是把MVC换掉，之前的DAL，BLL都不动。 MVC里的M和DAL/BLL里的一些模型（包括EF的实体类等）作用是不同的。当然，有时候为了减少冗余，会去设法在各个层之间通用统一的M；

[wyumening]

引用 7 楼 wjq 的回复:

MVC只是UI框架，代替的只是三层框架中的UI层，那些滥用MVC的把业务逻辑写到Controllor里的已经算是理解歪了，lz居然想拿M替代DAL和BLL，是我见过对MVC最歪的理解了~

那你的意思是说mvc只是ui框架，mvc中的model只是起到一个实体的作用，不能替代dll，bll? 也就是说有必要的时候再建立dll，bll层？也就是说mvc和三层在一个项目中可以共存，是这样子吗？

[完美的神速]

你说的Models是mvc中的一部分，各个公司开发习惯不同，之前的一家公司直接将Models文件夹删除，这样也可以，但是我感觉违背了mvc的理念。我现在自己写项目，基本上在Models中写一些逻辑，一个控制器对应一个Models，在控制器中只引用对应的Models类。

[1987andy]

可以，能解决你的实际问题，怎么样的结构都是允许的，mvc中models的存在仅仅是提供一种大众认可的比较好的项目结构而已

[csl_1022]

怎么舒服就怎么用呗

[丸子殿下]

就喜欢对mvc的讨论

[缪军]

引用 11 楼 wyumening 的回复:

[quote=引用 7 楼 wjq 的回复:] MVC只是UI框架，代替的只是三层框架中的UI层，那些滥用MVC的把业务逻辑写到Controllor里的已经算是理解歪了，lz居然想拿M替代DAL和BLL，是我见过对MVC最歪的理解了~

那你的意思是说mvc只是ui框架，mvc中的model只是起到一个实体的作用，不能替代dll，bll? 也就是说有必要的时候再建立dll，bll层？也就是说mvc和三层在一个项目中可以共存，是这样子吗？[/quote] 首先要弄清楚一件事,asp.netMVC不是MVC,就好比javascript不是java, asp.netMVC是工具集,对程序员而言,就是装模做样而已,实际上根本就没有分层,看看对象的命名就知道了; MVC是设计模式,狭义的概念:M:BusinessModel;V:ViewModel;C:ViewControllerAndBizModelController, 这不仅仅应用于Web,任何平台的桌面应用,移动应用都可以,并且可以轻松做到跨平台; 广义的MVC:M:提供者;V:消费者;C:代理人, 在这个层面上,MVC可以应用在软件生产的整个生命周期上

[paopao_426]

引用 5 楼 sp1234 的回复:

假设说你有60种数据实体，你有200个不同的界面，而且一年之内可能因为需求进化而增加（包括原来页面的大改）100个页面，那么你可能就总共有250个前端model，而还是保留原来60个三层里的model。这里的关系，就是“自由度”的问题。如果一个人能思想有自由度，他就能想接受着250个model，从而就能接受需求千变万化的结论；反之他就对提出需求变动的人表示各种不理解、或者不创新。

在mvc里新建适用于UI的model可以避免修改业务逻辑的Model这是非常赞同的。有点疑惑，当前端页面越来越多时，mvc的model也会越来越多，这种情况下有什么好的方案？mvc目前不支持返回动态对象给视图，可以通过datatable解决。从设计方面有什么好的方案吗？还有，业务逻辑的里的Model也需要新建许多dto与拼凑多个数据库表的的数据，有什么好的建议吗？

[缪军]

引用 17 楼 paopao_426 的回复:

。。。。。。有点疑惑，当前端页面越来越多时，mvc的model也会越来越多，这种情况下有什么好的方案？ 。。。。。。，有什么好的建议吗？

Model跟页面的多少没有关系，如果Model是基于领域设计的，甚至跟你的项目都没有关系， 同样的道理，View也和页面多少没有关系， 比如说你有ABCD，N个项目，他们总共有超过1万个界面， 而实际上，很可能View或者Model不会超过50个 再说一下控制器，一个UI平台，控制器只有一个