我在工作中继承了一堆程序,原作者使用Microsoft Visual Studio的数据组件(数据集,数据适配器等)在设计环境中(从工具箱或使用向导)创建.这产生了一些半定制的(专用于数据)类,并且还将SQL代码放入设计器生成的类中.
这不是我习惯做事的方式(我总是喜欢明确地拥有数据集,或者创建我自己的专用类来保存数据并隐藏底层数据层的复杂性).
有没有人有一些很好的见解或链接讨论使用Visual Studio数据组件的利弊？
(旁注,原作者也没有非常彻底地评论,并且根据我的口味,写了一些不太容易解释的"聪明"代码,所以我不倾向于认为他比我更了解.)
我想另一种提问方式是:使用数据设计器组件是否会产生"遵循最佳实践"且可维护的代码等？对我来说似乎不是这样,但我正在寻找专家的意见.
[编辑:增加了一些澄清意图的背景]
如果我是正确的(我看起来像是)关于使用最适合原型等的设计师组件,那么我将不得不与原始开发人员和我的经理进行一些艰难的对话.所以我想更多地强调"讨论利弊的链接"我的问题的一部分......我正在寻找一些可以用来支持我声称这种风格的开发/代码不是最多的东西适合生产使用......谢谢.
一般来说，视觉组件适用于一次性应用、POC 和尖峰应用，即原型设计。这有几个原因：他们很快就能聚在一起，但维持起来却是一场噩梦。我不确定您的应用程序的大小，但如果是我，我会认为在目前的形式下，拥有成本会随着时间的推移而增加，因此会更多地采用 DDD 风格的开发。将数据层装箱并用良好的实体 ORM 替换它；NHibernate（首选）或 Entity Framework 4（更容易入门）。丢掉那个“聪明的密码”并开始使用Kiss、Yagni、dry 咒语。让他们看到曙光可能很困难，但一旦成本开始降低，他们就会因此而爱你;)
如果您想在该领域进行更多阅读，请查看以下内容：
| 归档时间： |
|
| 查看次数： |
2789 次 |
| 最近记录： |