但是毕竟是 小项目——前端数据很少。
那么 在大型项目，比如一个大型项目的首页中，往往包含 几十种数据。
那么 这样的大型项目 MVC 也适用吗？
http://www.xiaomishu.com 就是用 Asp.Net 开发的。
如果用 MVC开发，那么 订餐小秘书 这个大型项目，复杂首页 MVC 该如何提供数据呢？
——————————————————————————
有木有 谁开发过 MVC 的大型项目，有 前端多数据提供 的经验，麻烦讲一下。
10 个解决方案
#1
mvc框架下面没有了服务器控件，自然也就没法像webform那样方便的使用gridview、repeater等等自带的或第三方的数据绑定控件。其实我个人感觉那些用起来也不是太好。。。
具体要实现起来mvc的方式无非就是ViewBag、ViewData保存对象集合，页面输出，或者直接return View(List<T>)、return View(Model)的形式返回强类型。这样页面展示的C#代码多少会比WebForm要复杂的多，所以也是现在很多人对MVC模式感觉不爽的地方，页面数据展示过多，页面代码结构会很难看。可以使用partialView来优化。
数据交付使用的是Ajax+Form表单
底层数据访问看项目具体需求了，这个和WebForm一样。
具体要实现起来mvc的方式无非就是ViewBag、ViewData保存对象集合，页面输出，或者直接return View(List<T>)、return View(Model)的形式返回强类型。这样页面展示的C#代码多少会比WebForm要复杂的多，所以也是现在很多人对MVC模式感觉不爽的地方，页面数据展示过多，页面代码结构会很难看。可以使用partialView来优化。
数据交付使用的是Ajax+Form表单
底层数据访问看项目具体需求了，这个和WebForm一样。
#2
ViewData 貌似可以保存很多 数据，就像一个Hash表，那么就是说 界面的数据 即使超过几十个 也都往其中 保存咯？
#3
3.0里面一般用ViewBag 灵活一点。 当然效率会有折扣。一个ViewBag 可以保存一个list集合。
或者你觉得太多，自定义类 包含这些集合对象也是不可以的。比如 你一个页面要展示Student的集合、Teacher集合、Class集合等等，你用一个自定义类都把他们定义为属性 public class Result
{
public List<Student> StudentList{get;set;}
public List<Teacher> TeacherList{get;set;}
...
}
查询好 后把 new 一个result的对象的属性赋值，然后 页面输出Reuslt。
mvc的模式就注定了只有 这几种方式来输出服务端的值。
#4
这种网页你也好意思是说事大项目，难道非要让我怀疑你是来打广告的
无非是显示一些数据 至于这么纠结么，
感觉拼接一个table或者div没有比神马数据源控件直接多了，也灵活多了
#5
当然适合。如果你是做门户网站，你需要使用缓存、分部视图。
#6
肯定可以的呀
#7
项目大不大和前端框架无关的。
只要业务逻辑封装的好，展示层可以随便替换的，甚至直接把bs改成基于webservice的cs也行
只要业务逻辑封装的好，展示层可以随便替换的，甚至直接把bs改成基于webservice的cs也行
#8
亲爱的，你真觉得 这个网站 是个小网站么？
好吧，没有经历过 亿万级数据的 菜鸟 飘过....
#9
彼此彼此
#10
你这个无非是怎么展示不同数据模块的问题，若按楼上有人说见局部视图，那显然要建很多，ViewBag、ViewData 之类的又非强类型；你定义个model不就完了（包含不同的数据列表属性实体类）：
model.NewsList、model.OrderList…
View：
foreach(var item in Model.NewsList){ … }
foreach(var item in Model.OrderList){ … }
model.NewsList、model.OrderList…
View：
foreach(var item in Model.NewsList){ … }
foreach(var item in Model.OrderList){ … }
#1
mvc框架下面没有了服务器控件，自然也就没法像webform那样方便的使用gridview、repeater等等自带的或第三方的数据绑定控件。其实我个人感觉那些用起来也不是太好。。。
具体要实现起来mvc的方式无非就是ViewBag、ViewData保存对象集合，页面输出，或者直接return View(List<T>)、return View(Model)的形式返回强类型。这样页面展示的C#代码多少会比WebForm要复杂的多，所以也是现在很多人对MVC模式感觉不爽的地方，页面数据展示过多，页面代码结构会很难看。可以使用partialView来优化。
数据交付使用的是Ajax+Form表单
底层数据访问看项目具体需求了，这个和WebForm一样。
具体要实现起来mvc的方式无非就是ViewBag、ViewData保存对象集合，页面输出，或者直接return View(List<T>)、return View(Model)的形式返回强类型。这样页面展示的C#代码多少会比WebForm要复杂的多，所以也是现在很多人对MVC模式感觉不爽的地方，页面数据展示过多，页面代码结构会很难看。可以使用partialView来优化。
数据交付使用的是Ajax+Form表单
底层数据访问看项目具体需求了，这个和WebForm一样。
#2
ViewData 貌似可以保存很多 数据，就像一个Hash表，那么就是说 界面的数据 即使超过几十个 也都往其中 保存咯？
#3
3.0里面一般用ViewBag 灵活一点。 当然效率会有折扣。一个ViewBag 可以保存一个list集合。
或者你觉得太多，自定义类 包含这些集合对象也是不可以的。比如 你一个页面要展示Student的集合、Teacher集合、Class集合等等，你用一个自定义类都把他们定义为属性 public class Result
{
public List<Student> StudentList{get;set;}
public List<Teacher> TeacherList{get;set;}
...
}
查询好 后把 new 一个result的对象的属性赋值，然后 页面输出Reuslt。
mvc的模式就注定了只有 这几种方式来输出服务端的值。
#4
这种网页你也好意思是说事大项目，难道非要让我怀疑你是来打广告的
无非是显示一些数据 至于这么纠结么，
感觉拼接一个table或者div没有比神马数据源控件直接多了，也灵活多了
#5
当然适合。如果你是做门户网站，你需要使用缓存、分部视图。
#6
肯定可以的呀
#7
项目大不大和前端框架无关的。
只要业务逻辑封装的好，展示层可以随便替换的，甚至直接把bs改成基于webservice的cs也行
只要业务逻辑封装的好，展示层可以随便替换的，甚至直接把bs改成基于webservice的cs也行
#8
亲爱的，你真觉得 这个网站 是个小网站么？
好吧，没有经历过 亿万级数据的 菜鸟 飘过....
#9
彼此彼此
#10
你这个无非是怎么展示不同数据模块的问题，若按楼上有人说见局部视图，那显然要建很多，ViewBag、ViewData 之类的又非强类型；你定义个model不就完了（包含不同的数据列表属性实体类）：
model.NewsList、model.OrderList…
View：
foreach(var item in Model.NewsList){ … }
foreach(var item in Model.OrderList){ … }
model.NewsList、model.OrderList…
View：
foreach(var item in Model.NewsList){ … }
foreach(var item in Model.OrderList){ … }