200分征求意见：我们的网站需求非常庞大，我全站都采用SQLHelper直接返回DataTable然后绑定Reapter的做法，没用实体类和架构，为了提高开发速度，这样做法有什么坏处没？

坏处说不上吧应该说开发的时候比较麻烦，假若若干页面有若干个修改某个实体数据的操作，那你不得不重复又重复的写SQL语句，
再假若数据表的结构有稍微的修改，那你修改调试的时候就更加难堪了，到处都要改，遗忘了什么也不知道...以上纯属只是个人想法，假若不存在以上假若，当我没说~~

框架没用过..
不过如果相同的功能可能考虑做成ascx的,维护起来方便点..

老狼怎么跑到asp.net版来混啦......
很少见你去asp了,现在是不是专混.net了.

全站都采用SQLHelper直接返回DataTable
这个问题大了啊，Dataset有时候还是很好的，特别是返回一个数据集的时候。如一个页面几十次的取数据。用DATASET只要取一次。
DataReader你不用？那么又可惜了。不用实体类，代码生成器照样用，用个简单的三层就够了。

返回数据的话用DataReader返回IList
其他重复的东西交给代码生成器就好了。 = =！
至少我都是这么开发的。。

showbo 你的头像太淫荡了希望可以换一个

建议用存储过程或sql分页的方法来进行查询操作(一次不要提取太多数据)
并且尽量多用datareader
当数据积累越来越多,访问量一上升,服务器性能会降的很厉害

存储过程或sql分页的方法肯定是用的了。
修改某单个实体数据的操作，我有一个通用的页可以完成全部表的增删查改。
对于多表的关联操作，我觉得不论怎样搞都麻烦，所以还是靠SQL基本功了。

我们的网站非常庞大，我全站都采用SQLHelper直接返回DataTable然后绑定Reapter的做法，没用实体类和架构，为了提高开发速度，这样做法有什么坏处没？
（实体类的代码生成器我也没用，因为我觉得实体类要不断修改完善巨麻烦）
------------------------------
我采用的和楼主也是一样的方法~~~确实觉得这个办法不是很好~~不过目前也没什么好的解决方法~~关注~~

我们也是取Dataset返回Tables[0],有时候叶面里是多个ASCX就需要多次取数据，不太方便用Dataset一次全部取回。不过我们有叶面生成静态，比缓存还厉害！~~~

需求庞大就比较麻烦
1.是每个界面所需要的数据不同，所以你的构造足够多的sql语句，这样修改起来牵连太多
2.后期维护，现在你必须把数据库的结构和字段表述和相互关系用文本详细的记下，不然东西一上线，估计两个月左右再让你改，你都不知道谁是谁了实际上分层的目的只是为了适应修改和变化，无所谓实体不实体（只要是适合变化的就可以，写东西前就应该考虑变化，至于实体层这类的东西，只不过就像是围棋里的定式，没人规定一定要按定式下，不过是按定式下不会吃啥亏，呵呵，这也并非绝对的事情，定式还分场合了，要都按定式下，那围棋就太没意思了，从头到尾背书就成了）

呵呵，狼兄原来也有问题啊。
asp版算没人看，都来这边了，不知道兔子过来没
“兔子与狼”也算传奇了

还是用实体类作中间传递的好。维护非常方便，编程的时候有代码提示，如果有备注的话鼠标放过去也能看见备注。如果直接用ds、dt、dr之类的东西的话，字段名字写错了都不知道，用实体类的话某个层调用的时候写错了编译时能发现。
用实体类在需要散落在代码的各个角落的话，能很方便的知道它是哪个表的。

恩，我也是和milozy1983 一样想的。业务逻辑有时候不清晰，关联的表会多达4-5个，实体类虽然能显示属性，可是很难把关联都做成新的实体。
比如：A-(AB关系表)-B-(BC关系表)-C-（CD关系表）-D
这里边就隐藏着A和C的关系，A和D的关系，B和D的关系。
那么你的代码生成器是否足够强大到做到这一点呢？

刚才数了一下，关联关系最长的链涉及了9个表。（就是要写8次inner join才能显示出全部关系）

我们开发人数少，只有4个程序员（包括我，但是我每天都要和部门外部打交道，基本处于随时被打断的状态）
最近正在招人，补充2个人，现在的毕业生让我失望，一问3不知，我把考题和名片送给他让他学成再来找我，我说如果你可以在CSDN 混2个星，我直接录用。我们的项目不难，就是任务量大，需要人多点。

就单单这一条说说：这种情况做报表还可以忍受，如果是web 的话查询太复杂了。
优化应该从数据结构开始。我觉得你的设计，数据结构可能太简单了，为了达到数据结构，数据库中表之间的松散耦合，而使具体业务逻辑查询时候查询复杂同样是没必要的。
上面人们所说的平衡很重要，是针对sql语句与业务实体代码的平衡。
同时也要考虑数据表与实际查询需求的平衡。
不可能有完全的平衡，从使用出发，考虑清楚在网站投入运营之后哪些查询量会比较大，从而针对这些建立
简单的-有索引的-有实体类支持的查询返回结果过程。

csdn混2个星估计不太难,我也是毕业生,你那话我留着,2个星的时候找你吖!哈哈~~建议可以用框架的话尽量用框架,便于开发和维护,而且可重用性强!还有就是,你说你们的系统很大,那么前期的需求分析一定要弄好,不然后面就惨咯,说什么实体类不完善,那就尽可能多了解需求再去下手,一个系统成败的关键是需求!

我和 LZ一样。都是直接一个 DBACCESS层一个BLL业务逻辑层。后来因为是一个人写。图方便把业务逻辑层都快省略没了。这样确实开发起来快了很多。不过也确实出现了之前LS有朋友说的过段时间就忘了哪是哪的问题。只好多写注释了

2个星没有
4个裤衩的要不
搞ASP.NET也有几年了
大大小小项目也做了十几个了
人在上海

象LZ这样做，开发起来是快的很
后期维护就可怜了
建议使用ORM

又见大笨狼上次你要招我的不知道还记得不哈哈看看大家也都说了差不多了 web项目三层是必须的吧...不然太不灵活了
而datatable最主要还是不易于维护在编写的时候也会因为数据类型之类的出问题所以还是用实体类~赶项目就用代码生成器吧
找个人花半天研究下
动软.Net代码生成器
最近做的两个项目都是用这个软件生成的代码~没什么问题的~

我是想如果代码生成器足够强大的话，就可以省去很多人的劳动，如果最终不大量节省人的劳动，还是不搞花样了。
我想做一个这样的代码生成器，比如输入两个表名，指定关系表，3个表+4个字段共7个条件，就可以生成A,AllA,B,AllB这样4个类比如学生类A和科目类B，是多对多的关系
A-AB关系-B
除了常规内建的数据类型属性外，还可以实现A.AllB和B.AllA，还有更进一步AllA.AllB,AllB.AllA,其中：
AllB是B的集合list<B>
AllA是A的集合list<A>
（就是：学生选择的科目们，选该科目的学生们;某几个学生选的科目们，某几个科目的学生们）自动生成增删查改的方法。注意一定要自动生成，我才不想让程序员手工实现这样的方法
（如果手工实现方法的话，还不如我们现在直接用DataSet）。只要设置下表的关系，代码就自动生成。有了这样的东西，我们将来的项目就可以真正实现实体化了，否则我觉得意义不大。上面说的这个东西谁有兴趣做？可以现金奖励。

可是即使有了上边这个东西，我想得到选择数学的全部女生，或者全部22岁的学生。还是要继续完善代码生成器。
比如想得到AllA.AllB="数学"的AllA,还是要动手写代码，想得到最后入学的10个学生也是要写代码。可实际项目就这么复杂的需求，代码生成器永远不可能足够完善，实体类永远不能足够完善。

用代码生成器生成出来的代码只可以帮助我们写一些重复的繁琐的代码而已,最终还是要按需调整的,如果生成器能够把所有的东西都写好那还要程序员干嘛呢我觉得现在制定代码生成器也晚了而且自己做个生成器只要想好需求了也并不是很难
但如果想用在你现在的项目上还要等做好测试反而会浪费时间总之datatable容易眼杂注释得写好了

想想满项目的sql语句真恐怖啊
为啥数据持久层不采用成熟的ORM框架来构建(Nbear不错).
楼主有空还是学习下企业应用架构和设计模式吧。

架构也不是说换就换的,考虑用生成器吧,生成大部分代码，小部分手写,总比全部手写强多了，partrial class还是很有用的

我是做C/S模式的，B/S很久没有做过了，我也认为用输出DataTable方式是可以提高开发速度(我也是这么做的),我个人认为无任是DataTable还是建立实体类没有太大的区别,我的意思是问题不在于选用何种数据源方式,问题在于在逻辑层怎么进行分离与控制,再住下说就可能说涉及到很多话题了，回到楼主的话题,从提高开发速度考虑是一个不错的选择;如果楼上的一些朋友所说DataTable的方式
维护不太方便的话，只能说逻辑层有问题,说到坏处DataTable的方式可能会使性能下降(DataSet对象层次太多了，很多都用不上，但依然为占用资源),这个缺点解决的方法还是很多的,我觉得不是什么大问题

其实，个人觉得就是如果分层设计，分实体层，业务层，表示层等。只是在开发编写代码比较方便简单，扩展伸缩性强，后期的维护性更好。至于程序的执行效率来说，.net的ado.net比其他的中间持久层都要高。

1，Nbear，Linq研究了半天不敢用啊，因为不是我一个人在战斗，需要团队学习的事情必须有一个精通的人在场,但是我自认为JS+SQL达到了国内3流（如果邹建、老孟、梅花算一流的话）我起码可以帮弟兄们打好基本功。2，我们好在功能需求比较明确（相对国内大多数团队而言），是用FreehandMX画出全部功能细节规则说明，缺什么让他们补什么，有5个我培训的可以上手的策划人（非程序员，他们即是需求提出人也是画图人也是编辑也是将来负责运营的人）在补充项目策划案。3，数据库图也是一流的,看
http://www.dullwolf.cn/databaseinfo.swf
这个更新后打印出来贴墙上和白板上，尺寸为900*1200mm。4，测试工作抓的比较紧，组织程序外的人包括上边提到的5个运营相关的人不停的提出细节修改，我利用Bug跟踪平台来控制优先级，分工和工。

看了老狼的数据设计
的确非常详细，不过还是有点东西可以讨论的。老狼这种设计实际上还是asp年代的做法（比较怀念“兔子”和“狼”和激情岁月）我现在通常不这么设计了（我也是最近几个项目才突然发现对对象这个东西有了了解），通常来说net下是先建立对象模型然后转制成数据库。所以数据库结构上也有变化了
像：企业表，用户表这块，我现在就不这么玩了，后面那一块非经常性搜索的东东，我现在只放一个字段了，这个字段只保存一个对象序列化后的xml信息就可以了，因为企业表，用户表类型很像所以基本是继承一个对象的，不同的那一块我继承不同的接口就是了，所以数据库只要放一个字段保存这个接口实例的序列化对象就可以了。
好处嘛：如果需要增减这些经常性搜索的字段，我也不必改数据库了，直接修改那个接口就是了论坛帖子这块也是一样：主题贴和回复贴实际上也差不多，他们也完全可以继承同一个东西，只不过他们之间有一定的关联性，所以大可以把关联性的地方用treenode ilist这样有一定层级关系的类封装一下，然后入库先说这么多好了，看其他人咋说

如果是从性能上考虑的话，并且是做网站的话，我有以下建议：
1.生成静态页面，因为动态页面的执行要经过一系列的处理，因为动态页面的处理包含提交ViewState，然后经过IIS的isapi.dll的解析，经由HttpModule,HttpHandler，还有页面的生存周期，然后发送包含大量ViewState的Html流到客户端，这样肯定是不如直接访问html页面来得快。
2.减少与数据库的交互，SQL Server并发能力有限，如果不做优化，并发数很高时，那么你可以看到数据库运行时CPU始终占99%，所以考虑分布式方式，数据库服务器单独一台，或者做成集群。ASP.NET 中，对于全局性的，或者是经常性访问的数据，要进行缓存，使用Cache。
3.我也经常使用DataTable，方便，但是，如果在并发数量高的时候，每个用户取一下数据，内存是否吃得消？所以你可以看到微软的一些开源程序都是用DataReader读取，结合实体层，放到List对象中，这样做，一个是读取速度快，第二个是占用内存少。毕竟DataTable对象占用的内存会大一些。所以你跑.net Web应用程序，内存越大越好，现在一般都4个G的内存。
4.在java中的web应用程序，大多使用一些成熟框架，如spring,hibernate框架，通过配置可以完成数据读取。我本人没用过nhibernate，不过据说其框架性能不如在jdk下的hibernate出色。java下是通过structs提交给servlet处理，在jsp上以request方式获取数据。抛开iis与tomcat(jboss)性能不谈。web服务器控件，viewstate，页面生成周期，是asp.net特别的东西，也是影响性能的。所以asp.net 3.5推出了asp.net mvc框架。也就是这个意图。
以上是一些个人观点，欢迎指正批评。

楼上的精彩！怀念ASP版在“狼”底下混的岁月了。

1,生成静态页面,我是采用截取ASPX页面的流生成HTML,然后后台有个开关控制每个页面是否跳过去,虽然对搜索引擎不太友好,可是省事还提高性能(能省则省).
2,SQL 优化肯定要搞的,尤其是针对inner join.
3,DataReader据说占用SQL连接?我也没太测试,占内存还好办也许,所以我选了DataTable.
4,spring,Nhibernate,Nbear等框架大概研究了一下,在工作量和性能上未敢信任,尤其是团队要洗脑,担心控制不了局面.mvc框架还不了解.

:)很久没去ASP版了,这个版主做的有点不称职,呵呵.
不过.NET中的重点,和所有Web开发一样,我感觉还是数据库+JS.
还有思路,以前ASP时代的着数技巧(奇技淫巧)都用得上.这次项目也许可以验证出一些道理,我也在等大量用户后的结果.

我也怀念那段快乐的时光,大家在里边玩的好开心啊,兔子虎子猪妹叉叉人类那些生物.....对象序列化后的xml信息,存储的还是个字符串,假设要搜索一个企业的所有人,还是要逐行去实例化用户,性能会比Select a inner join b on...好吗?要是找出企业所有人上传所有软件的所有图片,你怎么搞?
也许是我没想通,你全部数据都缓存了?直接在内存里实例化了?那样我的内存好象也不够啊.还有缓存后的更新机制以及命名空间也会增加开发复杂度吧?

我认为会影响一点效率，但是影响不大，但是如果不这么作的话，会多出很多工作。
打个比方，你可能多做了200%的工作，却只提升了3%的效率。
这个还是看你抉择了啊，我做项目也是图省事，一般是PetShop架构（代码生成的），或是nhibenate

大型网站高并发支持和高效稳定运行永远是“硬道理”
使用架构也不一定是解决所有问题的“银弹”
lz可以参考Discuz!NT良好设计的MVC和Cache层

还有，如果LZ这个项目已经开发了1/3甚至是一半以上了
现在再来使用代码生成器，难道又要重新架构？虽然业务逻辑程序员们应该已经都熟悉了
但是现在改又要增加工作量
使用代码生成器或者ORM还有一个问题就是不好调试
出了BUG，跟踪到生成的代码里，很有可能根本不知道问题出在哪儿，只能根据经验判断
现在LZ这么做至少好调试好找BUG，开发起来快，缺点就是满项目的SQL，业务逻辑扩展和维护起来麻烦

维护维护，你项目大了，逻辑复杂了管你用的是dt或者generic list + object 后期的维护都是一样的复杂
关键是看你团队人员是不是稳定，开发维护团队中最起码要有那么一两个老人从性能上看还是用 datareader好点吧
代码数量上看dt少多了，项目不大的话直接用dt方便省事
如果逻辑复杂还是建议用 object 要不后期开发不好管理一般我自己开发的东西都是用dt
公司团队开发都是用 list + object

用sqlhelper的话，他的分层观念很弱的
既然网站庞大，个人认为不太适合吧
没有实体和架构不太好啊

调试易

200分征求意见：我们的网站需求非常庞大，我全站都采用SQLHelper直接返回DataTable然后绑定Reapter的做法，没用实体类和架构，为了提高开发速度，这样做法有什么坏处没？

解决方案 »