Asp.net mvc, 在controller中进行数据读取操作是正确的做法么?
0
悬赏园豆：20
[已解决问题]
解决于 2010-03-26 11:32
例如某个Action如下
public ActionResult Details(int id)
{
var user = UserRepository.GetItem(id);
return View(new MemberViewModel() { User = user });
}
在这个action中调用了repository进行了数据读取,可是我查看一些资料说mvc模式是应该在model中进行数据读取的,似乎在controller中只进行view的选择.请问是这样么?如果是的话,可否告知model层具体怎样做?难道是再封装一次数据读取?
最佳答案
0
“可是我查看一些资料说mvc模式是应该在model中进行数据读取的”，这里的Model并不是指MVC里的Model。MVC是表现层的架构，这里的Model实际上是ViewModel，即供View进行展示的数据。ViewModel不包含业务逻辑，也不包含数据读取（就如同LZ的MemberViewModel）。
而在N层架构中，一般还会有一个Model层，用来与数据库的表相对应（如LZ的User），也就是所谓ORM中的O。这个Model可能是POCO，也可能是包含一些验证逻辑的实体类，一般也不包含数据读取。进行数据读取的是数据访问层，也就是LZ的UserRepository。而作为UI层的MVC一般不直接操作数据访问层，中间会有一个业务逻辑层封装业务逻辑、调用数据访问层。UI层（Controller）通过业务逻辑层来得到数据（Model），并进行封装（ViewModel），然后选择相应的View。
以上说的只是简单的N层架构，如果是分布式系统，可能还会有服务层、DTO层等等，就不赘述了。
不过，也没有必要严格遵循N层架构的模式。对于十分简单的系统，如果业务逻辑十分简单，只是到数据访问层相应方法的映射，那么完全可以剔除业务逻辑层，而像LZ那样直接通过Controller调用数据访问层。但对于相对较大的系统，业务逻辑复杂，不管将其置于Controller中还是数据访问层中，都会导致其臃肿，职责不单一。这时还是需要提供一个业务逻辑层的。
因此，LZ的做法适合小型简单的系统。对于稍复杂的系统，最好提供业务逻辑层，它不仅仅是“封装一次”数据读取，还封装业务逻辑。
收获园豆：10
Controller的职责是不是可以这样理解?它从业务逻辑层(MemberService)中获取数据,获得的是一个实体(MemberEntity),然后它控制返回一个View,并提供给这个View一个ViewModel?
@rad:基本上可以这样理解。不过MemberService中并不一定返回MemberEntity，还可能是整数、布尔值等等。Controller将数据整合成ViewModel，传递给View。
其他回答(2)
0
public ActionResult Index()
{
var judeges = EO.BLL.JudgeProblemManager.SelectJudgeProblem();
return View(judeges);
}
我也是这样获取的，今天看了很多文章，建议你看下：
http://www.cnblogs.com/daizhj/archive/2009/04/30/1447035.html 和
http://www.cnblogs.com/daizhj/archive/2009/02/26/1398689.html
我的个人感觉是，如果是三层迁移过来，就这么久行了。只是linq to sql 实在是太方便了。。。
收获园豆：5
0
我对asp.net mvc也是刚认识一点，也有类似的迷糊，
可是我查看一些资料说mvc模式是应该在model中进行数据读取的,
有这种说法么，model只是数据的载体，也就是在不同层之间（v和c）传输数据的.
------------------------------------------------------------------------
个人感觉(可能是所有的asp.net 示例程序造成的),asp.net 因为使用了linq，感觉linq允当了dal(数据操作层）,可能是orm模糊了数据操作层),这样，直接在control调用linq对象操作数据。
这样的话 control像是业务导，linq像是数据操作层了。
如果不使用linq,还是结合传统三层，control调用业务层。
---------------------------------------------------------------
不知这种理解对不对.
收获园豆：5
