使用Visual Studio设计器组件进行数据的优缺点是什么

Question

我在工作中继承了一堆程序，其中原作者使用Microsoft Visual Studio的数据组件（数据集，数据适配器等）在设计环境（从工具箱或使用向导）中创建。这产生了一些半定制的（专用于数据）类，并且还将SQL代码放入设计器生成的类中。

这不是我习惯做事的方式（我总是喜欢明确地拥有数据集，或者创建我自己的专用类来保存数据并隐藏底层数据层的复杂性。）

有没有人有一些很好的见解或链接讨论使用Visual Studio数据组件的优缺点？

（旁注，原作者也没有非常彻底地评论，并且根据我的口味，写了一些不太容易解释的“聪明”代码，所以我不倾向于认为他知道任何比我好。）

我想另一种问题是：使用数据设计器组件会产生“遵循最佳实践”且可维护的代码吗？对我来说似乎不是这样，但我正在寻找专家的意见。

[编辑：增加了一些澄清意图的背景]

如果我是正确的（看起来像我）关于使用最适合原型等的设计师组件，那么我将不得不与原始开发人员和我的经理进行一些艰难的对话。所以我想更多地强调“讨论利弊的链接”我的问题的一部分......我正在寻找一些可以用来支持我声称这种风格的开发/代码不是最多的东西适合生产使用......谢谢。

Answer 1

通常，可视组件适用于一次性应用，POC和尖峰应用，即原型设计。这有几个原因;他们很快就能聚在一起但是需要一个完整的噩梦来维持。我不确定您的应用程序的大小，但如果是我，我会争辩说，在目前的形式中，所有权成本会随着时间的推移而增加，因此会更多地考虑DDD的开发风格。将数据层加起来并用一个好的实体ORM替换它; NHibernate（首选）或实体框架4（更容易进入）。删除“聪明的代码”并开始使用Kiss, Yagni, dry mantra。可能很难让他们看到光明，但一旦开始花费更少，他们就会爱你;）

如果您想在此区域阅读更多内容，请查看以下内容：

1. Skill Matter是一个培训机构，可以运行开放式会话和大量可以观看的播客
2. Dev和管理人员阅读的好书是Ship IT，它着眼于良好的项目实践。与实用书架上的任何内容一样，
3. Martin Fowlers' blog所有DDD
4. Ayende's blog是所有NHibernate
的好地方
5. stackoverflow.com，这个地方摇滚

Answer 2

VS数据组件的目的是快速开发应用程序。从这个角度来看，你可以看到它的优点和缺点：

专业人员：快速开发，不需要太多编码和知识。适用于将来不会更改的小型应用程序。

缺点：打破层组合应用程序设计逻辑（此处添加此类设计的所有优点），将所有文件合并在一起。 因此几乎不可能动态替换数据源。使更复杂的大型应用程序支持。 DI，TDD - 使用它是一件神秘的事。

实际上这是一个非常广泛的问题。 我建议阅读有关N层应用程序开发和测试驱动开发的更多信息

希望这个帮助

Answer 3

我甚至不会说设计师数据库组件适合POC或原型设计。这些组件在Visual Studio中主要作为框架的销售推销，因此微软可以说“哇，看看用.NET创建数据驱动的应用程序是多么容易！”它们应该在几年前被删除，恕我直言。

但是，不要将设计器组件与ADO.NET（即DataTables，DataSet，DataReader，DataAdapter等）本身混淆。由于您继承的应用程序是围绕设计器组件构建的，这意味着它也基本上是围绕ADO.NET组件构建的。您可以（并且应该）摆脱设计器组件，但您也不一定要摆脱ADO.NET。

Answer 4

我个人认为你肯定是在正确的轨道上，但是这真的取决于你已经拥有的东西以及对产品未来的计划。

我已经看到了正如您所说的那样使用的生产代码并且工作正常，并且在某种程度上易于维护。 甚至包括Telerik这样的大型公司的模块也有一些大幅下降，这些公司属于您所谈论的同一类开发项目。

我认为对您的雇主来说，真正重要的因素是：您可以用什么方式以最快最有效的方式完成工作。我会说，总的来说，直接开箱即用的“拖放”工具对于长期企业级应用程序来说并不是很好。

以下是Charles Petzold撰​​写的一篇文章，可能为您提供更多“专家”凭据信息。

http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html