如何说服我的同事不要使用数据集进行企业开发(.NET 2.0+)

与我合作的每个人都沉迷于以数据为中心的企业开发方法,并讨厌使用自定义集合/对象的想法.说服他们的最佳方法是什么？

1> Mark Biek..：

---

通过例子做到并轻轻地踏上.任何更强大的东西都会让你与团队的其他成员疏远.

记得考虑一下他们错过的东西的可能性.成为团队的一员意味着轮流学习和教学.

没有一个人能得到所有答案.

2> Jon Limjap..：

---

如果您正在处理遗留代码(例如,从.NET 1.x移植到2.0或3.5的应用程序),那么离开数据集将是一个坏主意.为什么改变已经有效的东西？

但是,如果您正在创建新应用,那么您可以引用一些内容:

在维护坚持使用DataSet的应用程序时遇到痛苦

引用新方法的性能优势

诱饵他们有一个良好的中间地带.转移到.NET 3.5,并推广LINQ to SQL,例如:虽然仍然坚持数据驱动架构,但是对字符串索引数据集来说是一个巨大的,巨大的背离,并强制执行......瞧!自定义集合 - 以对它们隐藏的方式.

重要的是,无论你使用什么方法,你都保持一致,而且你对你的方法的利弊完全诚实.

如果所有其他方法都失败了(例如,你有一个开发团队完全拒绝从旧的做法中退出并且对学习新事物持怀疑态度),这是一个非常非常明确的迹象,表明你已经超出你的团队离开公司的时候了. !

---

让我们看看...... L2S已经死了...... EF正在重修......嘿!数据集似乎相当稳定,也许我们应该使用它们!;-)

---

@stephbu - 和EF正在大幅修改,所以两者(目前的形式)都不是长期的好赌注.但L2S需要较少的投资/复杂性,因此(考虑到当前的流量)使其比EF IMO更具吸引力.

---

"Linq to SQL已经死了"这些天似乎是一个网络模因.像大多数网络模因一样,没有人知道它来自哪里,而且它是荒谬的.

3> Orion Edward..：

---

记得考虑一下他们错过的东西的可能性.成为团队的一员意味着轮流学习和教学.

借调."企业发展"在某种程度上不同于(通常意味着"比'更重要')正常发展的整个想法真的令我烦恼.

如果使用某些技术确实有好处,那么您需要提出一个考虑清单,列出切换后可能出现的所有优缺点.
将此列表提供给您的同事以及每个人的解释和示例.

创建此列表时必须切合实际.你不能只说"节省我们很多时间!!!赢!" 没有解决这样一个事实,即有时需要花费更多时间,需要X个月才能加快新技术的开发速度等等.你必须展示具体的例子,它将节省时间,以及确切的方式.

同样地,你不能仅仅因为无所谓而轻描淡写,你的同事会打电话给你.
如果你不做这些事情,或者只是推动你个人喜欢的事情,那么没有人会认真对待你,而你只会因为充满热情和精力但却不知道的人而享有声誉什么都有.

BTW.留意这个特殊的骗局.除非你的所有其他东西都有很多强大的案例,否则它将胜过一切:

需要12个月以上的时间来移植我们现有的代码.你输了.

---

4> icelava..：

---

当然,"这取决于"情况.有时,DataSet或DataTables更适合,例如它实际上是非常轻的业务逻辑,实体/记录的平面层次结构,或具有一些版本控制功能.

当您想要实现无法在平面2D表中有效表示的对象的深层次结构/图形时,自定义对象集合会闪耀.您可以演示的是一个对象的大图,并使某些事件沿正确的分支传播,而不会在其他分支中调用不适当的对象.这样就没有必要循环或选择通过每个DataTable来获取子记录.

例如,在我两年半前参与的项目中,有一个UI模块应该在单个WinForms DataGrid中显示问题和答案控件(更具体地说,它是Infragistics的UltraGrid).一些更棘手的要求

问题的答案控件可以是任何内容 - 文本框,复选框选项,单选按钮选项,下拉列表,甚至可以弹出可以从Web服务中提取更多数据的自定义对话框.

根据用户的回答,它可以触发更多子问题直接出现在父问题下.如果稍后给出不同的答案,则应该公开与该答案相关的另一组子问题(如果有的话).

最初的实现完全是用DataSet,DataTables和数组编写的.在多个表中循环数百行的数量纯粹令人费解.它没有帮助程序员来自C++后台尝试引用所有内容(你好,生活在堆中的对象使用引用变量,比如指针!).没有人,甚至是最初的程序员,都无法解释为什么代码正在做它的功能.在这之后的六个多月里,我进入了这个场景,并且它充满了臭虫.难怪我接手的第二代开发人员决定退出.

为了解决混乱局面而花了两个月的时间,我自己将整个模块重新设计成一个面向对象的图来解决这个问题.yeap,完成抽象类(根据问题类型在网格单元格上呈现不同的答案控件),委托和事件.最终结果是2D数据网格绑定到深层次的问题,自然地根据父子安排进行排序.当父问题的答案发生变化时,它会向孩子提出一个问题,他们会根据父母的答案自动显示/隐藏他们在网格中的行.只有该路径下的问题对象才会受到影响.与旧方法相比,该解决方案的UI响应性是数量级的.

5> MusiGenesis..：

---

具有讽刺意味的是,我想发布一个与此完全相反的问题.我使用过的大多数程序员都使用了自定义数据对象/集合方法.看到有人在一台显示器上打开SQL Server表定义,在另一台监视器的Visual Studio中慢慢键入一个匹配的行包装类(每个列都有私有属性和getter-setter),这让我心碎.如果他们也倾向于创建60列表,那就特别痛苦.我知道有些ORM系统可以自动构建这些类,但我已经看到手动方法的使用频率更高.

工程选择总是涉及可用选项的优缺点之间的权衡.以数据集为中心的方法有其优点(类似于db-table的内存中实际数据库表示,由知道他们正在做什么的人编写的类,对大型开发人员池熟悉等),自定义数据对象也是如此(编译类型检查,用户不需要学习SQL等).如果贵公司的其他人都在使用DataSet路由,那么至少从技术上来说,DataSet是他们正在做的事情的最佳选择.