问题描述
长期搞c/s架构的企业局域网软件，b/s搞的少，而且在搞webform（木有玩过mvc），也不觉得wpf多好多好，所以讨论围绕webform，请大牛们畅所欲言。1、页面展现列表数据的时候，局部刷新，用的比较多的就是$.ajax调用后台代码或者ashx文件，针对一些数据量较小的列表数据，通常都是用html+css画界面（这种列表展现的数据量较小，不会有翻页、排序的要求）。问题来了，如果数据量较大有翻页、排序的要求，再用html+css去自己画页面并实现排序、分页，这个搞起来感觉有点复杂了。不想用asp:gridview这个玩意，发布的页面会生成一堆垃圾东西，调样式也烦。大牛们都是怎么实现这种列表展现数据的？局部刷新+列表（翻页、排序）2、asp.netwebform做工作流，有木有经验介绍下，工作流这块没接触过。分数不多了，都拿出来，希望大牛们不吝赐教。顺祝端午节安康！
解决方案
解决方案二：
如果经常使用前端框架，那么grid的翻页（或者是下拉时动态瀑布式增加）一点也不麻烦，通常也就是4、5行javascript代码。如果你能把自己常用的模式封装成类型（如果使用typescript会比原生javacript语言更接近于c#），那么就会封装为自己熟悉的“1行代码完成功能”。如果你重点在于前端，那么当你创建aspx的时候，第一件事就是把EnableViewstate属性设置为false，或者是把页面上的默认产生的<formrunat="server>删除掉。这样你的页面就是无回发机制的了。你看几乎所有的关于asp.netmvc的博客，一开始假设以大篇幅来“黑”webform的时候，都是围绕着ViewState来说的。很显然，如果你真的是前端js开发很厉害，那么你就应该彻底关闭asp.net传统的回发机制。asp.net传统的回发机制与ajax机制实际上是相互竞争、相会对立的，无法调和。
解决方案三：
凡是那种5、6行代码或者“1行代码”就为前端grid增加数据行的框架，你可以注意一下，都是数据驱动的。也就是说，当你对数据集合进行更新，例如代码varself=this;jQuery.get("data/index.json",function(d,s,r){vararr=d.data1;for(var_i=0,arr_1=arr;_i<arr_1.length;_i++){varx=arr_1[_i];self.data1.push(x);}arr=d.data2;for(var_a=0,arr_2=arr;_a<arr_2.length;_a++){varx=arr_2[_a];self.data2.push(x);}});
这个代码就是从服务器下载了数据，然后把下载来的两个数据集合中的记录push到本地的数据集合。而前端框架，此时就自动更新UI了，例如自动为2个grid表格增加了许多新记录。如果你的脑子里还是“用js代码来操作dom”，那么你比较out了。这就会写出很垃圾的前端代码。js代码和dom/html代码，应该分开成为两层。而不应该纠结在一起。
解决方案四：
不管做什么企业应用，业务逻辑的重点都在于后台、在于内功。通常设计好的业务服务层开放个几十家前端开发商去使用，当没人买你的“工作流系统服务”的时候，你们才应该自己先做一套工作流系统前端出来。这是架构一个大的企业系统的基础思路。所以如果你只是会一点页面编程，你所谓的“工作流系统”一般来说也就是随便说说，深入不下去。只有那些有魄力、能够把前端“包出去”的人，才能设计好一个后台系统框架。我不是说真的要把前端开发给包出去，我是说要有这种能力，要把前端跟后端分得很清。从2015年以来，国内出现了一帮很垃圾的“全栈工程师”，其实就是一些做网页的，号称自己是全栈工程师。其实他们也还是做小网站，烧一些无脑的投资人的钱。而真正的全栈工程师，必须有非常丰富的服务器设计开发经验！然后再加上前端技术。
解决方案五：
数据量大的解决方法肯定是从分页查询数据开始的，其实对于显示来说，还是一页一页的内容显示出来，查询慢是因为数据库结构不合理或者数据冗余问题比较严重，代码结构不合理等原因引起的。跟前端的显示方式关系不大。你的这个问题是因为C/S的一般结构是把数据全都传到客户端，之后代码来画出界面，全部的东西都要自己在客户端处理。B/S的结构可以是一页一页得获取数据。关于工作流的问题，它只是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。跟实现的方式无关。
解决方案六：
可以看ko官网上的一个入门级的例子。这个例子没有什么美工概念，所以Grid的样式看上去非常普通，主要是演示了ko的理念。你可以看到，代码很少，代码围绕着mvvm中的vm而不是针对v来编写的。（我们不用这个页面这类的入门ko知识，我们使用ko的“template绑定”即使，并且动态下载模板、动态下载数据，无限伸展地应用ko模型。）而你说的“用xxxxx去翻页、排序时感觉有点复杂”这些话，其实编程设计方式完全是极其原始的js程序员的方式。编程设计的理念上的区别，其实要比代码更重要。就好像小说里说的，所谓“九阴真经、葵花宝典”很难找，但是不难练。
解决方案七：
举个例子，当用户点击AddProduct按钮时，你可以看代码，只是执行了一行代码self.addLine=function(){self.lines.push(newCartLine())};
然后你就看到界面上多了一行初始化数据，并且这行都初始化好了（例如准备好了Category下来列表）。其它的mvvm式的操作也是如此，编程都是非常简单。可以随时读取当前用户录入的所有数据、合计等等，而不需要操作dom；反之增加上删除或者排序object.lines属性数组，也会自动更新到UI。这可以解决你的你的根本问题——重学web前端。
解决方案八：
该回复于2016-06-12 12:34:50被版主删除
解决方案九：
引用6楼sp1234的回复:
举个例子，当用户点击AddProduct按钮时，你可以看代码，只是执行了一行代码self.addLine=function(){self.lines.push(newCartLine())};然后你就看到界面上多了一行初始化数据，并且这行都初始化好了（例如准备好了Category下来列表）。其它的mvvm式的操作也是如此，编程都是非常简单。可以随时读取当前用户录入的所有数据、合计等等，而不需要操作dom；反之增加上删除或者排序object.lines属性数组，也会自动更新到UI。这可以解决你的你的根本问题——重学web前端。
问一个问题：上面的展示出的代码中的self.data1.push(x);是从数据库中查出的原始的数据结构吗？在添加的到自己的data1中的时候，在data1中再拼接html字符串？？追加到当前的dom中？？？
解决方案十：
引用6楼sp1234的回复:
举个例子，当用户点击AddProduct按钮时，你可以看代码，只是执行了一行代码self.addLine=function(){self.lines.push(newCartLine())};然后你就看到界面上多了一行初始化数据，并且这行都初始化好了（例如准备好了Category下来列表）。其它的mvvm式的操作也是如此，编程都是非常简单。可以随时读取当前用户录入的所有数据、合计等等，而不需要操作dom；反之增加上删除或者排序object.lines属性数组，也会自动更新到UI。这可以解决你的你的根本问题——重学web前端。
还是在后台查询出数据后，就在后台拼接好响应的html字符串？？
解决方案十一：
一楼牛人,五连回复.
解决方案十二：
引用4楼fxj805835819的回复:
数据量大的解决方法肯定是从分页查询数据开始的，其实对于显示来说，还是一页一页的内容显示出来，查询慢是因为数据库结构不合理或者数据冗余问题比较严重，代码结构不合理等原因引起的。跟前端的显示方式关系不大。你的这个问题是因为C/S的一般结构是把数据全都传到客户端，之后代码来画出界面，全部的东西都要自己在客户端处理。B/S的结构可以是一页一页得获取数据。关于工作流的问题，它只是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。跟实现的方式无关。
感谢这位兄台的回复！估计您看出帖子了，我提问里面不是探讨大数据量查询慢的问题（丝毫没有这种字眼）
解决方案十三：
估计您看错帖子了，我提问里面不是探讨大数据量查询慢的问题（丝毫没有这种字眼）
解决方案十四：
引用8楼yan_hyz的回复:
Quote: 引用6楼sp1234的回复:
举个例子，当用户点击AddProduct按钮时，你可以看代码，只是执行了一行代码self.addLine=function(){self.lines.push(newCartLine())};然后你就看到界面上多了一行初始化数据，并且这行都初始化好了（例如准备好了Category下来列表）。其它的mvvm式的操作也是如此，编程都是非常简单。可以随时读取当前用户录入的所有数据、合计等等，而不需要操作dom；反之增加上删除或者排序object.lines属性数组，也会自动更新到UI。这可以解决你的你的根本问题——重学web前端。
问一个问题：上面的展示出的代码中的self.data1.push(x);是从数据库中查出的原始的数据结构吗？在添加的到自己的data1中的时候，在data1中再拼接html字符串？？追加到当前的dom中？？？
+1同问@以专业开发人员为伍
解决方案十五：
看p哥的评论很爽
解决方案：
gv是生成很多垃圾的viewstate.不过easyui生成的"垃圾"似乎大于gv....那么多垃圾就是为了"好看",我觉得不值得."它"的运行效率真的大于gv吗?使用起来真的比"gv"方便快速吗?呵呵.
解决方案：
引用8楼yan_hyz的回复:
Quote: 引用6楼sp1234的回复:
举个例子，当用户点击AddProduct按钮时，你可以看代码，只是执行了一行代码self.addLine=function(){self.lines.push(newCartLine())};然后你就看到界面上多了一行初始化数据，并且这行都初始化好了（例如准备好了Category下来列表）。其它的mvvm式的操作也是如此，编程都是非常简单。可以随时读取当前用户录入的所有数据、合计等等，而不需要操作dom；反之增加上删除或者排序object.lines属性数组，也会自动更新到UI。这可以解决你的你的根本问题——重学web前端。
问一个问题：上面的展示出的代码中的self.data1.push(x);是从数据库中查出的原始的数据结构吗？在添加的到自己的data1中的时候，在data1中再拼接html字符串？？追加到当前的dom中？？？
为什么一定要是数据库的原始结构？不要纠结于数据库，最简单的用于各个层之间的model，可以是跟数据库表一一对应，这是最简单的，但一般还会有一个model，是UI用的。。。比如说，你的表有班级表，有学生表，学生表中有一个字段是班级ID，表示学生属于哪个班级，那么，我们平时用的model就是两个model，一个班级，一个学生，但我上面说UI用的那个model，可能也是两个，一个是班级model，这个班级model中有一个学生model的数组，表示这个班级的学生。。。
解决方案：
既然你脱离服务器控件，那你可以easyui+ajax+handler。至于你说的分页，都交给easyui就可以了。设置pagination:true。后台接收参数pageNumber,pageSize就可以了。（分页查询，一般就是对数据库分页查询）说白了，如果你注重前台，想摒弃asp.net的回发机制。那么就应该多关注前台的第三方控件，例如jq-ui,easyui等等。
解决方案：
分页、排序啥的都有js控件，其实你可以认为服务器控件搬到了客户端，当然自己html+js其实也没啥的，如果公司有UI组的话，基本你必须要按照UI提供的html原型组织html+js进行展示
解决方案：
1.你还停留在控件的层面2.大数据量的分页，不会傻傻的直接取全表的数据分页3.看看redis之类的缓存
解决方案：
我一般都不用aspx.net的控件，最好是用html原生控件，这样和js、cs可以简单高效的配合，不用生成一堆垃圾css和js
解决方案：
分页有专门的jq插件，前端传入页数，后端直接在库里取数，很方便的
解决方案：
引用19楼Joyhen的回复:
1.你还停留在控件的层面2.大数据量的分页，不会傻傻的直接取全表的数据分页3.看看redis之类的缓存
1、大数据指定不会一下子load到页面，页切换采取重新检索（可以从数据库load或者使用缓存）2、没有停留在控件的层面上，是b/s搞的少，小数据量都是ajax+json画界面（不用easyui或者gridview控件）
解决方案：
引用21楼lshfong的回复:
分页有专门的jq插件，前端传入页数，后端直接在库里取数，很方便的
easyui的grid算一个
解决方案：
引用17楼hanjun0612的回复:
既然你脱离服务器控件，那你可以easyui+ajax+handler。至于你说的分页，都交给easyui就可以了。设置pagination:true。后台接收参数pageNumber,pageSize就可以了。（分页查询，一般就是对数据库分页查询）说白了，如果你注重前台，想摒弃asp.net的回发机制。那么就应该多关注前台的第三方控件，例如jq-ui,easyui等等。
嗯，关注easyui这个插件了
解决方案：
这种列表展现可以就使用你所说的小数据的展现方式，只不过大数据多了分页而已，你所要查询的数据库查询好之后，用分页展示，比如：有10W条数据库，每页显示50条，那么在数据库查询的时候，没次只查询50条数据，相应的显示50条数据，这样就是UI界面只用处理50条小数据了
解决方案：
引用25楼u013961050的回复:
这种列表展现可以就使用你所说的小数据的展现方式，只不过大数据多了分页而已，你所要查询的数据库查询好之后，用分页展示，比如：有10W条数据库，每页显示50条，那么在数据库查询的时候，没次只查询50条数据，相应的显示50条数据，这样就是UI界面只用处理50条小数据了
那么就要对Html画的table或者div做分页了，而且需要对table或者div列头加排序
解决方案：
我和你的情况类似，但是中间我曾经做过1年的webfrom的开发，如果要用的话，建议去看一下DTcms这个开源的项目，他里面的数据表呈现都是用的repeater来做的，分页用的一个asp的插件，挺好用的！比着写就行了！
解决方案：
webform和winform有很多相似之处大多数基于事件的驱动。webform有自己的控件和winform一样。只是控件的用法有差异。底层基本都一样。MVC是winformMVC现在是MVC5基本上有点像以前的ASP但是只是有一点像。MVC是微软对抗JAVA J２EE MVC推出的。基于RAzor语法是全新的设计模式，完全脱离了事件驱动。就HTML+RAzor+JS+CSS+后台代码+数据库。底层差不多。主要是视图交互完全脱离了基于事件的驱动
解决方案：
通过你上述问题MVC完全适合你。MVC就是拜托webform控件的垃圾反应速度请求模式。webform=aspx+aspx.csMVC=html+cs没有控件MVC+easyUI=前端前端+你以前的后端经验=现在解决问题的优势也就是说MVC=htmlaspx=服务器+请求=html
解决方案：
楼主应该是才开始做asp.net开发，其实asp.net开发不一定要用微软的那些控件，直接html+ajax+jquery已经足够了，与asp.netwebform以及mvc无关
解决方案：
和楼主一样，我接触微博webform两年多时间了，都是自己摸索实现的系统功能，列表用gridview还是listview还是datagrid,repeater之类的，数据源绑定还是后台代码事件实现等等，看情况而定，分页自带的也行使用插件都可以，自带的样式有点丑，可以找些好看的参考参考。工作流方面的我还是建议参考一些OA框架，自己写一定很麻烦而且不一定好用，借鉴下别人的定制自己的，时间和效率上会有很大提升。MVC方面有时间还是接触接触。