我在工作中继承了一堆程序,其中原作者使用Microsoft Visual Studio的数据组件(数据集,数据适配器等)在设计环境(从工具箱或使用向导)中创建。这产生了一些半定制的(专用于数据)类,并且还将SQL代码放入设计器生成的类中。
这不是我习惯做事的方式(我总是喜欢明确地拥有数据集,或者创建我自己的专用类来保存数据并隐藏底层数据层的复杂性。)
有没有人有一些很好的见解或链接讨论使用Visual Studio数据组件的优缺点?
(旁注,原作者也没有非常彻底地评论,并且根据我的口味,写了一些不太容易解释的“聪明”代码,所以我不倾向于认为他知道任何比我好。)
我想另一种问题是:使用数据设计器组件会产生“遵循最佳实践”且可维护的代码吗?对我来说似乎不是这样,但我正在寻找专家的意见。
[编辑:增加了一些澄清意图的背景]
如果我是正确的(看起来像我)关于使用最适合原型等的设计师组件,那么我将不得不与原始开发人员和我的经理进行一些艰难的对话。所以我想更多地强调“讨论利弊的链接”我的问题的一部分......我正在寻找一些可以用来支持我声称这种风格的开发/代码不是最多的东西适合生产使用......谢谢。
答案 0 :(得分:3)
通常,可视组件适用于一次性应用,POC和尖峰应用,即原型设计。这有几个原因;他们很快就能聚在一起但是需要一个完整的噩梦来维持。我不确定您的应用程序的大小,但如果是我,我会争辩说,在目前的形式中,所有权成本会随着时间的推移而增加,因此会更多地考虑DDD的开发风格。将数据层加起来并用一个好的实体ORM替换它; NHibernate(首选)或实体框架4(更容易进入)。删除“聪明的代码”并开始使用Kiss, Yagni, dry mantra。可能很难让他们看到光明,但一旦开始花费更少,他们就会爱你;)
如果您想在此区域阅读更多内容,请查看以下内容:
答案 1 :(得分:1)
专业人员:快速开发,不需要太多编码和知识。适用于将来不会更改的小型应用程序。
缺点:打破层组合应用程序设计逻辑(此处添加此类设计的所有优点),将所有文件合并在一起。 因此几乎不可能动态替换数据源。使更复杂的大型应用程序支持。 DI,TDD - 使用它是一件神秘的事。
实际上这是一个非常广泛的问题。 我建议阅读有关N层应用程序开发和测试驱动开发的更多信息
希望这个帮助
答案 2 :(得分:1)
我甚至不会说设计师数据库组件适合POC或原型设计。这些组件在Visual Studio中主要作为框架的销售推销,因此微软可以说“哇,看看用.NET创建数据驱动的应用程序是多么容易!”它们应该在几年前被删除,恕我直言。
但是,不要将设计器组件与ADO.NET(即DataTables,DataSet,DataReader,DataAdapter等)本身混淆。由于您继承的应用程序是围绕设计器组件构建的,这意味着它也基本上是围绕ADO.NET组件构建的。您可以(并且应该)摆脱设计器组件,但您也不一定要摆脱ADO.NET。
答案 3 :(得分:0)
我个人认为你肯定是在正确的轨道上,但是这真的取决于你已经拥有的东西以及对产品未来的计划。
我已经看到了正如您所说的那样使用的生产代码并且工作正常,并且在某种程度上易于维护。 甚至包括Telerik这样的大型公司的模块也有一些大幅下降,这些公司属于您所谈论的同一类开发项目。
我认为对您的雇主来说,真正重要的因素是:您可以用什么方式以最快最有效的方式完成工作。我会说,总的来说,直接开箱即用的“拖放”工具对于长期企业级应用程序来说并不是很好。
以下是Charles Petzold撰写的一篇文章,可能为您提供更多“专家”凭据信息。
http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html