与我一起工作的每个人都痴迷于以数据为中心的企业开发方法，并且讨厌使用自定义集合/对象的想法。以其他方式说服他们的最佳方法是什么？
Toran Billups
问问题
1818 次
16 回答
21
以身作则，小心行事。任何更强大的东西只会让你与团队的其他成员疏远。
记住要考虑他们可能会错过你错过的东西。成为团队的一员意味着轮流学习和教学。
没有一个人拥有所有的答案。
于 2008-09-01T02:39:21.547 回答
10
如果您正在处理遗留代码（例如，从 .NET 1.x 移植到 2.0 或 3.5 的应用程序），那么离开数据集将是一个坏主意。为什么要改变已经有效的东西？
但是，如果您正在创建一个新的应用程序，您可以参考以下几点：
- 呼吁在维护坚持使用 DataSets 的应用程序时遇到痛苦
- 引用新方法的性能优势
- 用一个好的中间立场来引诱他们。迁移到 .NET 3.5，并推广 LINQ to SQL，例如：虽然仍然坚持数据驱动的架构，但对字符串索引数据集是一个巨大的、巨大的背离，并强制执行......瞧！自定义集合——以一种对他们隐藏的方式。
重要的是，无论您使用哪种方法，您都必须保持一致，并且您对您的方法的优缺点完全诚实。
如果所有其他方法都失败了（例如，你的开发团队完全拒绝改变旧的做法并且对学习新事物持怀疑态度），这是一个非常非常明确的迹象，表明你的团队已经超出了你的团队，是时候离开你的公司了！
于 2008-09-01T03:09:06.450 回答
9
记住要考虑他们可能会错过你错过的东西。成为团队的一员意味着轮流学习和教学。
借调。“企业发展”在某种程度上与正常发展不同（通常暗示“比”更重要）的整个想法确实让我感到厌烦。
如果使用某些技术确实有好处，那么您需要想出一份经过深思熟虑的清单，列出您转换后会出现的所有利弊。
将此清单连同每个清单的解释和示例一起呈现给您的同事。
创建此列表时，您必须切合实际。您不能只说“为我们节省了很多时间！！！赢了！！” 如果不解决有时需要更多时间的事实，将需要 X 个月的时间来加快新技术的速度等。您必须展示具体的例子，它可以节省时间，以及如何节省时间。
同样，您不能只是绕过缺点，好像它们无关紧要，您的同事会打电话给您。
如果你不做这些事情，或者被认为只是在推动你个人喜欢的事情，没有人会认真对待你，你只会得到一个充满热情和精力但不知道的人的名声关于任何事情。
顺便提一句。留意这个特殊的骗局。它将胜过一切，除非您对所有其他内容有很多强有力的案例：
- 需要 12 个月以上的时间来移植我们现有的代码。你输了。
于 2008-09-01T03:00:31.090 回答
7
当然，“这取决于”情况。有时 DataSets 或 DataTables 更适合，比如它真的是非常轻量级的业务逻辑、实体/记录的平面层次结构，或者具有一些版本控制功能。
当您想要实现无法在平面二维表中有效表示的对象的深层层次结构/图形时，自定义对象集合会大放异彩。您可以演示的是一个大型对象图，并让某些事件沿着正确的分支传播，而不会在其他分支中调用不适当的对象。这样，就不必为了获取子记录而循环或选择每个 DataTable。
例如，在我两年半前参与的一个项目中，有一个 UI 模块应该在单个 WinForms DataGrid 中显示问题和答案控件（更具体地说，它是 Infragistics 的 UltraGrid）。一些更棘手的要求
- 问题的答案控件可以是任何东西- 文本框、复选框选项、单选按钮选项、下拉列表，甚至可以弹出一个自定义对话框，该对话框可以从 Web 服务中提取更多数据。
- 根据用户回答的内容，它可以触发更多子问题直接出现在父问题下方。如果稍后给出不同的答案，它应该公开与该答案相关的另一组子问题（如果有的话）。
最初的实现完全用 DataSets、DataTables 和数组编写。循环遍历多个表的数百行的数量纯粹是令人费解的。它没有帮助来自 C++ 背景的程序员尝试引用所有内容（你好，堆中的对象使用引用变量，如指针！）。没有人，即使是最初的程序员，也无法解释为什么代码会做它所做的事情。六个多月后，我来到了现场，那里仍然充斥着虫子。难怪我接手的第二代开发者决定退出。
为了解决这个混乱的问题，我花了两个月的时间把整个模块重新设计成一个面向对象的图来解决这个问题。是的，包含抽象类（根据问题类型在网格单元格上呈现不同的答案控件）、委托和事件。最终结果是一个 2D 数据网格，绑定到问题的深层层次结构，根据父子排列自然排序。当父问题的答案发生变化时，它会向子问题引发事件，并且它们会根据父问题的答案自动在网格中显示/隐藏他们的行。只有沿该路径的问题对象受到影响。与旧方法相比，此解决方案的 UI 响应能力提高了几个数量级。
于 2008-09-01T03:12:35.287 回答
5
具有讽刺意味的是，我想发布一个与此完全相反的问题。我合作过的大多数程序员都采用了自定义数据对象/集合方法。看到有人在一台监视器上打开他们的 SQL Server 表定义，在另一台监视器中慢慢地在 Visual Studio 中键入匹配的行包装器类（每列都有私有属性和 getter-setter），这让我心碎。如果他们也倾向于创建 60 列的表，那就特别痛苦。我知道有些 ORM 系统可以自动构建这些类，但我看到手动方法使用得更频繁。
工程选择总是涉及可用选项的优缺点之间的权衡。以 DataSet 为中心的方法有其优势（实际 db 数据的类似 db-table 的内存表示、由知道自己在做什么的人编写的类、大型开发人员池熟悉等），自定义数据对象也是如此（编译类型检查，用户无需学习 SQL 等）。如果您公司的其他人都在走 DataSet 路线，那么至少从技术上讲，DataSet 是他们所做工作的最佳选择。
于 2008-11-08T13:58:38.720 回答
3
数据集/表格还不错吧？
我能给出的最好建议是在你自己的代码中尽可能多地使用它，并希望通过同行评审和错误修复，其他开发人员将看到代码如何变得更具可读性。（确保在这些事件发生时推动这一点）。
最终，如果代码有效，那么剩下的就是语义是我的观点。
于 2008-09-01T02:25:32.217 回答
2
我想你可以尝试推销 O/R 映射和映射器工具的想法。将行视为对象的好处非常强大。
于 2008-09-01T02:40:55.067 回答
2
我认为你应该专注于表现。如果您可以创建一个应用程序来显示使用数据集与自定义实体时的性能差异。此外，尝试向他们展示领域驱动设计原则以及它如何适应实体框架。
于 2008-09-01T03:26:23.290 回答
2
不要把它变成宗教或信仰的讨论。那些很难赢（反正不是你想要的）
不要像您在问题中所做的那样构建它。问题不在于让任何人同意这种方式或那种方式是他们应该工作的一般方式。您应该讨论每个人需要如何思考才能在任何给定时间做出正确的选择。举例说明何时使用 dataSet，何时不使用。
我让开发人员使用 dataTables 来存储他们从数据库中获取的数据，然后使用该 dataTable 编写业务逻辑代码......我向他们展示了我如何减少加载页面的时间，从 100% CPU 的 7 秒（在网络上）服务器）到根本看不到 CPU 线移动。通过将内存对象从数据表更改为哈希表。
所以举一个例子或案例，你的事情以不同的方式更好地实施，并赢得这场战斗。不要打高水平的战争...
于 2008-09-01T07:41:29.837 回答
2
如果互操作性是/将是一个问题，DataSet 绝对不是正确的方向。您可以通过服务公开 DataSets/DataTables，但是否应该或值得商榷。如果您在谈论 .NET->.NET，您可能没问题，否则您将有一个非常不满意的客户端开发人员从栅栏的另一边消耗您的服务
于 2009-04-02T06:27:47.007 回答
1
否则你无法说服他们。选择一个较小的挑战或转移到不同的组织。如果你的经理尊重你，看看你是否可以以领域驱动风格做一个项目，作为一种技术试验。
于 2008-09-01T03:17:54.340 回答
1
如果您可以配置文件，请执行并配置文件。数据集比简单的更重Collection<T>
数据读取器比使用适配器更快...
改变对象的行为比按摩数据集容易得多
不管怎样：就做吧，请求原谅而不是许可。
于 2008-09-01T05:15:19.953 回答
1
大多数程序员不喜欢偏离他们的舒适区（请注意，“大多数程序员”集和“堆栈溢出”集的交集可能是空集）。“如果它以前有效（甚至刚刚有效），那么继续这样做”。我目前正在进行的项目需要很多参数才能让年长的程序员使用 XML/模式/数据集，而不仅仅是 CSV 文件（该软件的先前版本使用 CSV）。它并不完美，模式在验证数据方面不够健壮。但这是朝着正确方向迈出的一步。我开发的代码在数据集上使用 OO 抽象，而不是传递数据集对象。一般来说，最好以身作则，一次一小步。
于 2008-09-01T08:50:58.237 回答
0
这里已经有一些非常好的建议，但如果你需要支持的只是一些关于 stackoverflow 的支持性评论，你仍然需要说服你的同事。而且，如果他们像听起来那样怀疑，那么您将需要更多弹药。首先，获取 Martin Fowler 的“企业架构模式”的副本，其中包含对各种数据访问技术的详细分析。阅读。然后强迫他们全部阅读。
任务完成。
于 2008-12-14T14:51:15.817 回答
0
以数据为中心意味着更少的代码复杂性。
自定义对象意味着可能需要组织、维护和通常使用的数百个附加对象。它也会快一点。
我认为这确实是一个代码复杂性与性能的问题，可以通过您的应用程序的需求来回答。
于 2009-07-02T19:53:31.307 回答
0
从小处着手。有没有一个实用应用程序可以用来说明你的观点？
例如，在我工作的地方，主应用程序有一个复杂的构建过程，包括更改配置文件、安装服务等。
所以我写了一个应用程序来自动化构建过程。它有一个基本的 WinForms UI。但由于我们正在转向 WPF，因此我将其更改为 WPF UI，同时保留 WinForms UI，这要感谢 Model-View-Presenter。对于不熟悉 Model-View-Presenter 的人来说，这是一个易于理解的示例，可以参考。
同样，找一些小的东西，你可以向他们展示非 DataSet 应用程序的外观，而无需进行重大的开发投资。
于 2009-12-14T20:24:34.483 回答