与我一起工作的每个人都痴迷于以数据为中心的企业开发方法，并且讨厌使用自定义集合/对象的想法。否则，说服他们的最佳方法是什么？

解决方案

回答

数据集/表还不错吗？

我能提供的最好建议是，在我们自己的代码中尽可能多地使用它，并希望通过同行评审和错误修正，其他开发人员将看到代码如何变得更具可读性。 (请确保在发生这些情况时加紧说明)。

最终，如果代码可以正常工作，那么我认为剩下的就是语义。

回答

以身作则，轻而易举。任何更强大的事情都会使我们与团队中的其他成员疏远。

记住要考虑到他们错过了我们错过的东西的可能性。成为团队的一员意味着轮流学习和教学。

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

回答

我想我们可以尝试推销O / R映射和映射器工具的想法。将行视为对象的好处非常强大。

回答

Remember to consider the possibility that they're onto something you've missed. Being part of a team means taking turns learning & teaching.

借调。关于"企业发展"的整个想法在某种程度上不同于正常发展(通常的含义是"比……更重要")确实让我感到烦恼。

如果使用某种技术确实有好处，那么我们需要拿出一份经过深思熟虑的清单，列出所有因使用该技术而产生的利弊。
将此列表提供给同事，以及每个同事的解释和示例。

创建此列表时，我们必须现实一点。我们不能只说"为我们节省了很多时间！WIN ！！"却没有解决有时会花费更多时间的事实，需要X个月的时间来加快新技术的开发速度，等等。我们必须显示一些具体的示例来节省时间以及确切的时间。

同样，我们不能只顾缺点而已，即使它们无关紧要，同事也会打电话给我们。
如果我们不做这些事情，或者遇到的只是推销自己喜欢的事情，那么没人会认真对待我们，我们将以成为一个充满热情和活力但不懂事的人而享有声誉关于任何事情。

顺便提一句。留意这个特殊的弊端。它将胜过一切，除非我们在其他所有方面都有很多有力的理由：

• 移植我们现有的代码需要12个月以上的工作。你输了。

回答

如果我们正在处理旧版代码(例如，从.NET 1.x移植到2.0或者3.5的应用程序)，那么离开数据集将是个坏主意。为什么要更改已经起作用的东西？

但是，如果我们要创建一个新的应用程序，则可以引用以下内容：

• 呼吁在维护坚持使用DataSet的应用程序时遇到痛苦
• 引用新方法带来的性能优势
• 用良好的中间立场引诱他们。例如，移至.NET 3.5，并将LINQ升级为SQL：尽管仍坚持数据驱动的体系结构，但它是对字符串索引数据集的巨大替代，并强制执行...瞧！自定义集合-以隐藏的方式显示。

重要的是，无论我们使用哪种方法，都应保持一致，并且对方法的优缺点完全诚实。

如果所有其他方法都失败了(例如，开发团队完全拒绝接受旧的做法并且对学习新事物持怀疑态度)，则这是一个非常非常明确的信号，表明团队已经不足够了，该离开公司了！

回答

当然，"取决于"情况。有时，DataSet或者DataTables更适合，例如业务逻辑确实很轻巧，实体/记录的层次结构统一或者具有某些版本控制功能。

当我们要实现无法在平面2D表中有效表示的对象的深层次结构/图形时，自定义对象集合会发光。我们可以演示的是一个大型对象图，并使某些事件向下传播到正确的分支，而无需在其他分支中调用不合适的对象。这样，就不必为了获取子记录而在每个DataTable中循环或者选择。

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

• 问题的答案控件可以是任何内容-文本框，复选框选项，单选按钮选项，下拉列表，甚至是弹出自定义对话框都可以从Web服务中提取更多数据的控件。
• 根据用户的回答，它可以触发更多子问题直接出现在父问题下。如果以后给出了不同的答案，则应该公开与该答案有关的另一组子问题(如果有)。

原始实现完全用DataSet，DataTables和数组编写。遍历多个表的数百行的数量纯粹是令人费解的。它并没有帮助程序员来自C ++后台，它试图引用所有内容(我们好，堆中的对象使用引用变量，如指针！)。没有人，甚至不是最初的程序员，都无法解释为什么代码会执行其工作。在此之后的六个多月，我走进了现场，那里充斥着许多虫子。难怪我接任的第二代开发人员决定退出。

为了解决混乱的混乱局面，我花了两个月的时间重新设计整个模块，使其成为一个面向对象的图形，以解决此问题。是的，还有抽象类(根据问题类型在网格单元上呈现不同的答案控制)，委托和事件。最终结果是将2D dataGrid绑定到深层次的问题，并根据父子安排自然排序。当父级问题的答案更改时，它将引发一个事件给子级问题，并且它们将根据父级答案自动在网格中显示/隐藏其行。仅该路径下的问题对象受到影响。与旧方法相比，此解决方案的UI响应速度提高了几个数量级。

回答

我们无法说服他们。选择一个较小的挑战或者转到其他组织。如果经理尊重我们，我们会看到我们是否可以将域驱动样式的项目作为一种技术试用来进行。

回答

我认为我们应该专注于表现。如果我们可以创建一个应用程序，该应用程序在使用"数据集"与"自定义实体"时显示性能差异。另外，尝试向他们展示域驱动设计原理以及它如何与实体框架相适应。

回答

如果可以进行概要分析，则只需执行并进行概要分析即可。数据集重于简单的Collection <T>

与使用适配器相比，DataReader更快。

更改对象的行为比按摩数据集要容易得多。

无论如何：只要做就做，请求宽恕而不是允许。

回答

请勿将其视为宗教或者信仰讨论。这些很难赢(无论如何你都不想要)

不要以我们刚才在问题中所做的方式来构架。问题在于没有任何人同意这种方式或者这种方式是他们应该工作的一般方式。我们应该讨论每个人在任何给定时间做出正确选择所需的思考方式。举例说明何时使用dataSet，何时不使用。

我让开发人员使用dataTables存储从数据库中获取的数据，然后使用该dataTable进行业务逻辑代码...并且向他们展示了如何减少加载页面的时间，而该过程花费了100％CPU占用7秒(在Web上)服务器)以完全看不到CPU线的移动..通过将内存对象从dataTable更改为Hash表。

因此，举个例子或者案例，我们可以更好地实施不同的方案，从而赢得这场战斗。不要打高级别的战争...

回答

大多数程序员不喜欢偏离自己的舒适区(请注意，"大多数程序员"集和"堆栈溢出"集的交集很可能是空集)。 "如果它在之前(或者什至只是在起作用)就起作用了，那就继续做下去"。我目前正在从事的项目需要很多争论，才能使年长的程序员使用XML /方案/数据集而不是CSV文件(该软件的先前版本使用CSV)。这不是完美的，架构在验证数据方面还不够强大。但这是朝正确方向迈出的一步。我开发的代码在数据集上使用OO抽象，而不是传递数据集对象。通常，最好以身作则，每次只做一小步。

回答

具有讽刺意味的是，我想提出一个与此完全相反的问题。与我合作的大多数程序员都使用了自定义数据对象/集合方法。看着某人在一个监视器上打开他们的SQL Server表定义，然后在另一个监视器中在Visual Studio中缓慢键入匹配的行包装器类，我很伤心(每列都有私有属性和getters-setter)。如果他们也容易创建60列表，这将特别痛苦。我知道有些ORM系统可以自动构建这些类，但是我已经看到手动方法的使用频率更高。

工程选择始终涉及在可用选项的优缺点之间进行权衡。以数据集为中心的方法(自定义数据对象)有其优点(像db表一样在内存中表示实际的db数据，由知道自己在做什么的人编写的类，对大量开发人员熟悉的类等) (编译类型检查，用户不需要学习SQL等)。如果贵公司的其他所有人都在使用DataSet，那么从技术上讲，DataSet至少是他们所做工作的最佳选择。

回答

这里已经有一些非常好的建议，但是如果我们要支持的全部只是关于stackoverflow的一些支持性意见，我们仍然可以说服同事。
而且，如果他们像听起来那样持怀疑态度，那么我们将需要更多弹药。
首先，获得Martin Fowler的"企业体系结构模式"的副本，其中包含对各种数据访问技术的详细分析。
阅读。

然后强迫他们全部阅读。

回答

任务完成。

回答

如果互操作性是关注的重点，那么DataSet绝对不是正确的方向。我们可以通过服务公开DataSet / DataTables，但无论我们应该还是值得商bat。如果我们使用的是.NET->。NET，那么可能还可以，否则我们将遇到另一个非常不满意的客户端开发人员，它会消耗服务

以数据为中心意味着更少的代码复杂性。

自定义对象意味着可能有数百个其他对象可以组织，维护和使用。它也会更快一些。

回答

我认为这实际上是一个代码复杂性与性能的问题，可以通过应用程序需求来回答。

从小开始。是否有实用工具可以用来说明观点？

例如，在我工作的地方，主应用程序具有复杂的构建过程，涉及更改配置文件，安装服务等。

所以我写了一个应用程序来自动化构建过程。它具有基本的WinForms UI。但是由于我们正朝着WPF迈进，因此我将其更改为WPF UI，同时还要保留WinForms UI，这要归功于Model-View-Presenter。对于那些不熟悉Model-View-Presenter的人来说，这是一个可以理解的示例。

段落数量不匹配