做个小调查,多少人在用asp.net数据源控件?该如何解决
做个小调查,多少人在用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
就是说做网站的时候用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