如果其他人和我一样感到好奇.对我来说,控件如datagrid/gridview/formview/etc. 非常适合演示或演示.要花时间调整这些控件,覆盖它们的默认行为(挂进他们的愚蠢事件等)是一件非常令人头疼的问题.我使用的唯一控件是转发器,因为它为我提供了最大的灵活性.
简而言之,它们几乎是臃肿软件.
我宁愿编织自己的html/css,使用我自己的自定义分页查询.
同样,如果您需要快速浏览这些控件,那么这些控件非常棒(特别是如果您试图让人们了解.NET开发的简易性).
我必须是少数,否则MS不会在这些类型的控制上投入如此多的开发时间......
任何认为没人使用*Grid控件的人显然从未在内部企业webapp上工作过.
我几乎都在编写自己的HTML - 我正在使用ListView和Masterpages,但实际上并没有真正使用控件.顺便说一句,我的ListView嘲笑你那个愚蠢的老式中继器.
但是,英国媒体报道不一定是件坏事.如果我需要构建一个低容量的Intranet应用程序,我宁愿付出一个经验不足的开发人员拖放控件而不是HTML twiddler(像你或我)来制作每个标签.这里有一个快速,简单的方法.只要基于控件的代码以可维护的方式编写,那么在这种情况下"bloatware"的成本是多少？通常布线控制需要较少的自定义代码,这意味着简单的维护.
我不得不反对你的一个地方 - 几乎不管应用程序 - 都在制作你自己的分页查询.你可能喜欢这样做,但它绝对没有商业价值.有几种专业级DAL工具通常会编写比大多数开发人员更易维护,更快速的查询.即使您精心制作完美的分页查询,它也无法及时更新架构,除非您继续花费数小时的时间.我认为更好地利用这些时间是建立一个轻量级系统,并将这些时间用于监视和修复特定的瓶颈,而不是立即跳转到"数据库汇编语言"层.
我一直在读你的帖子,这让我感到愚蠢.
我的意思是在我工作的每个应用程序中,其中至少有一个datagrid/gridview.而且我没有感觉我错过了什么.
当然,我发现datagrid/gridview有点臃肿,但是它们使用起来有多恶心吗？
我认为在你谴责它们之前你需要学会使用GridViews.我广泛使用它们.起初,弄清楚某些事情有点挑战,但现在它们是不可或缺的.
使用AJAX CRUD和分页的UpdatePanel中的GridView很快.以这种方式设置的较大系统之一(用于内部/外部应用程序)在后端具有适度大小的数据库.有许多nvarchar(2000)字段,转换和更新都很棒.
无论如何,如果您编写了自己的显示数据版本,则可能需要继续使用它.(可以用来编写自己的编译器,编写自己的HTML版本,编写自己的数据访问二进制版本......)使用GridView的优点是有很多人熟悉它并且MSFT已经抽象/建模了这个类来做很多我们以前必须手动完成的事情.
京公网安备 11010802040832号 | 京ICP备19059560号-6 