MVC中view页面不要涉及到业务代码，这句怎么理解？
MVC中view页面不要涉及到业务代码，这句怎么理解？，有时页面中确实要与业务打交道，怎么办？难道每次都要去cotroller处理？能不能直接在页面用c#代码处理？比如在一个grid中，我返回的是list<student>，要在grid中把男性同学且分数低于60的标为红色，还要统计所有女性同学的平均值，这些操作是不是要去服务器操作后返回值？ --------------------编程问答-------------------- 你可以在controller里边，或者业务逻辑层里边把平均值算好，然后用viewbag传到页面，页面引用一下就行。 和你返回的model list<student>没有冲突 --------------------编程问答-------------------- view 一边就起到一个显示排版的作用，没有必要把业务逻辑弄到前台，后台处理更方便，前台弄还要写一堆js --------------------编程问答--------------------但是有些操作一定是在前台进行的啊，譬如在gridview上修改数据，把数据删掉同时变背景色，难道要把整个数据源list<student>装进viewbag??不然没操作一次我就得跟controller打交道,controller有得跟db打交道，而且每次都跟DB打交道不合理吧？？ --------------------编程问答-------------------- 1.业务代码并不说UI上需要的数据就叫业务代码
2.>60就显示红色，这明显是UI的事情，不是什么业务的事情
3.求平均马马虎虎能算业务，但是也不是所有业务都一定要在后端，如果性能没什么影响，而且他也就只在一个UI里生效，那也挺多只能算一个场合业务，就一个UI场景使用的场合业务一般不纳入业务范围，因为他和具体UI相关属于变化较快，但实现快速，并且本身就和其他场景隔离，所以就算你不把他纳入统一管理范畴其影响也可以忽略不计（除非你合同和设计书上明确纳入考量目标了，这玩意才算正式业务，其他时间这种就一个UI使用的，而且没什么性能影响的东西暂时不纳入思考范围，因为设计师有更重要的事情要考虑，才不会为了一个既不影响性能也不存在非常大的联动耦合的要求多费啥脑浆） --------------------编程问答-------------------- 这是一种想当扯淡的有害说法。如果说“Controller不要依赖于View而设计”这个很容易理解，但是反不过来说的话，就完全是胡说八道了。任何前端应用程序，View都是集大成者、最终目标。只不过我们要承认View应该是千变万化的，因此我们要让专业的交互设计师甚至美工人员轻松地搞定View，因为他们在“像素级”保证了产品吸引用户的眼球，而不要让那些习惯于纠结死板的编程代码的程序员去纠结于View。只有这个角度才能说这是View与数据模型和控制是分层的。如果说View的设计脱离业务需求，那么就彻底是纸上谈兵最终害人害己了。 --------------------编程问答-------------------- 但是反不过来说的话，就完全是胡说八道了 --〉 但是反过来说的话，就完全是胡说八道了
不是说View不涉及业务，而是说你要充分考虑到View必须适应千变万化地快速迭代甚至推倒重来，所以它应该采取极端快速的声明式、帮定式、行为注入式的开发方法。不是说这个部分不设计业务，而是应该提高十倍开发效率去开发View。 --------------------编程问答-------------------- 同意老p的说法，一般来说除非设计要求指明的具有明确考量目标的边际方法，或者耦合性比较大的需要防范的东西才在业务里特别处理，一般情况下业务层尽量不要去过多限制，尽量提供通行的可以灵活变动的对象给外面，总的来说也就是核心业务和必须解耦的尽量稳定可控，而外延部分则尽量通行灵活（外延部分限制过死，实际并不利于项目，很多公司的所谓3层之所以让人别扭，就是因为完全不加区分，只死背所谓的分层框框，结果把该稳定可控的东西弄滴不可控了，而该灵活应对的东西有限制死了，结果谁都别扭，从上到下没一个人舒坦） --------------------编程问答--------------------
不单单是>60才显示红，还要性别为男的，如果直接是td的值，用text就搞定了。就是业务比较复杂，不知道是在每次修改都去controller查，还是直接把list<student>取到view --------------------编程问答--------------------
你还是不理解啊，什么叫UI，现在你就做把。做完了，我告诉你就这个页面，我告诉你我不光要红滴，我还要<60的显示绿滴，100分滴显示个大红花还要闪啊闪啊滴
你认为这个在那里修改最方便。 --------------------编程问答--------------------
按照这种需求两种方法都有缺陷，不知道那种效率高？
1.在ui改变颜色和求平均值，需要遍历table（或者难道table的数据源），然后判断性别和分数,每次修改如果值<60并性别是男的，又得改变背景色，有点复杂
2.在control直接查，判断，每次与数据库打交道 --------------------编程问答--------------------
平均值（男性同学)用viewbag在服务器算后返回客户端，改变背景色load整个model然后再view变色，等全部操作完后到数据库保存一次？ --------------------编程问答--------------------
有一点点明白，谢谢wanghui0380和sp大叔，不知道我上面的说法对不对 --------------------编程问答-------------------- 比如说你的服务api返回了一组“用户信息”数据，每一个用户有“年龄、心率”数据，而你的界面上除了显示这两个信息（以及其他基础数据）以外还要显示此人有多大概率是心脏病人，那么这个数据属于什么层次的计算呢？
实际上这要实事求是！有些死读书的人（而且有点小聪明的人），他就会偷偷地去修改前端的中间层的数据结构设计，去硬生生地加上“心脏病概率”这个字段。他的理由可能就是你的那个话。实际上他心里真实的想法是为了偷懒，而明明知道这个字段是冗余的、会造成数据自相矛盾而不顾，以为他找到了“View不要涉及业务概念”的借口了。
实际上View的开发中不可能把自己当作一个只会绘图渲染“技术”的傻瓜，不论是数据模型、控制、绑定、数据转换等等，都要不断地从View层设计者那里吸取营养，因为只有最接近用户需求和操作体验的那一层往往才最懂终端用户需求变化。前端技术中分层设计，不像传统的网络三层那样非常鲜明地分层，但是目的是类似的，并不是说我们要提取稳定的业务逻辑于是就不注重最终表现了，而是为了轻松快速地改变界面样式。 --------------------编程问答--------------------
这个需求还设计到修改值，如果<60也变色(存数据库），所以就弄不清楚在哪边处理，如果直接变色在ui，编辑变色平均值 --------------------编程问答-------------------- 并不是所有的逻辑都一定和数据库有关系，假设你后面还有一堆业务需要用到及格，不及格，满分，优秀这类判定，那么可以有公用逻辑判定，但也一定只是及格，不及格这等逻辑而不是red,green这种逻辑
ps：view又不是不允许你写UI层逻辑代码,那raroz来说
@model list<student>
@{
view里同样可以求到你要求的平均
var avg=Model.where(p=>p.sex=="女").avg(p=>p.分数);
}
view里同样可以很方便的显示自定义规则
@helper display(decimal 分数)
{
if(分数>60)
<font color=red>@分数.ToString()</font>
else
@分数.ToString()
}
补充：.NET技术 , ASP.NET
