做个小调查,多少人在用asp.net数据源控件?
就是说做网站的时候用vs提供的数据源控件连接数据库.
我觉的数据源控件就像dw里提供的数据库连接组件,好用,就是灵活性差,不方便控制.
摆脱数据源控件,自己写连接类是迈向高手的重要一步,不知道我理解的对不对.
------解决方案--------------------从没用过
------解决方案--------------------
------解决方案--------------------
------解决方案--------------------不是重要的一步,而是最基础,最底层的一步。
------解决方案--------------------从没用过
------解决方案-------------------- 虽然不是高手,不过没用过。
------解决方案--------------------没用过,
写一个调用sql语句和存储过程的类,所有项目都可以公用,只要修改连接字符串就OK了
------解决方案--------------------从来没用过
------解决方案--------------------用过,但是学了新东西就搞忘了
------解决方案--------------------查询的地方用,但添加修改似乎始终和普通的开发模式不一致,一般的添加修改模式都是弹出新窗口或者在另外一个窗口进行的,而且还可能需要html在线编辑器,而控件一般绑定的都是就地修改的。
------解决方案--------------------项目中几乎不用
------解决方案--------------------vs2003时用代码连接数据库,
vs2005开始用数据源控件ObjectDataSource,代码至少少了50%,
调用存储过程也方便不少,
没觉得有什么不灵活!
------解决方案--------------------额,vs的设计者是从delphi挖过来,所以设计的时候也保留了delphi的一些特征
但是,这东西用在winform和快速原型上比较合适,用在webform上是弊大于利
用在winform上是因为微软在“智能化数据控件“上下了很大功夫,很多智能化接口在winform上很不错,比如Inotifychange,Ibingingsouce都是非常不错,非常智能化的东西,而在winform中所有绑定同一个数据源的控件,在这些智能接口下都能同步更新,同步变化数据,这是非常好的特性。而且这些东西的编程性也不错,即使你不拖动数据源控件,而采用代码去实现效果上也没区别
但是在webform上由于http无状态的特殊性,这些智能化特性都已经失效了,即使后来有补上了ajax这块,也只能说差强人意,而且如果说在大量页面中去使用这些拖动过来的数据源控件,在软件工程管理上也存在太多不受控的因素
ok你看明白吗,webform下既失去了智能化,同时又失去了工程控制性,一样好处都没有,那么谁还用呢??
当然用处是存在滴,那就是快速原型开发,我们只是要给客户看快速原型的时候,我们才会使用这种方式
------解决方案--------------------既然微软开发出了这个方法(数据控件来调用数据),如果你自己写,那还不一样的,也许从某个角度讲你是对,可是你的功能没有办强大。甚至很弊端。我还是习惯用数据控件吧!他能解决大部分问题。
------解决方案--------------------仅仅在做测试的时候用过。。。。。。。。
------解决方案--------------------
------解决方案--------------------
------解决方案--------------------用不用控件跟是不是高手没有任何关系,自己写连接类也不是为了显示自己可以摆脱控件从而脱离菜鸟群体。如果是团队开发自然要服从整体规划,如果是个人开发当然义无反顾地用。
------解决方案--------------------数据源控件没有你们说的那么不堪.
因为控件最终还是要调用你自己写的数据访问类. 而数据源控件在某种程序上可以简化你的程序逻辑.
------解决方案--------------------我挺喜欢ObjectDataSource的。
------解决方案--------------------没用过+1