其实我觉得把题目换成“程序设计你向误区走了多远”。可是想想既然是发在.net社区了，还是改成目前的名字吧。
首先声明一点：我说的仅仅是个人的观点，不说憋得慌，您要是看的不爽，私下里骂两句的了。但是别说出来。这和意淫还是“真淫”一样。前者你是好人，后者你就是坏淫^_^
1）被用烂了的“接口”，其实interface本身只是用来规范子类的。当然我承认：随着时代的发展，我们会给事物赋予新的职责，但问题是你给事物赋予了太多的职责本身是否合适。就像现在的“小姐”这个词一样，这本来能算是一个褒义词的，结果时代进不了，它被划定到“绝对的，及其无耻的贬义词”阵营了。interface也处在一个及其尴尬的位置，因为它被赋予的职责太多了，多到了让人觉得会压垮interface的地步:今天弄一个“转换”,隐藏具体实现；明天弄一个“依赖注入”，实现什么松耦合。我们不觉得太残忍了么？它本身就是用来规范子类，而现在却被绝对的本末倒置了。甚至让人们觉得interface的定义有问题了。
2）已成“弃子”的parameter(dataadapter的输入参数），因为推崇“依赖注入”的人都觉得“看到一堆的parameter就烦。我觉得说出这种话的人，绝大多数偶读是从java转过来的，要不就是根本没用过sql server数据库。其实输入参数本身是sql server解决注入攻击的最好办法之一（另外一个就是存储过程，其实存储过程本身也要靠输入参数支持一把的），因为sql server可以在一个command中执行多个sql语句的,而oracle不可以，所以有人就鼓吹oracle如何如何了，在这点来说并不是Oracle本身比sql server好，而是Oracle在这点上偷懒了。或许您会不同意，说出如何如何的观点，那我问您：在一个有自增列的表中我插入了一条记录，然后获得这个id。sql server是“平地一声雷”一次搞定，而Oracle却要“脱一次裤子”才行。
4）过分的追求“松耦合”，甚至很多人都把“无耦合”当成最终目标了。虽然很多人都在鼓吹“依赖注入”，甚至把懂这个东西、在项目中使用了这个东西当成一种荣耀当成一种资本。但是有一点是肯定的：不管是“依赖注入”还是所谓松耦合（把松耦合和依赖注入放到一起不合适），其本身并没有改变耦合的本质，只是把以前的一步走变成了两步走或者是n步走了。一步走3米能做到，但是肯定不合理，但是3米走10步恐怕只有变态才会觉得好。而松耦合也是这个道理：你到底是要把“3米”松到“几步”中？“依赖注入”可以看做是把原来的一步变成了3步：第一步：我想上你。第二步：等等我去配置文件中看看给你配置了没有。第三步：不好意思没您的事。分层固然是符合N多的设计理念，但是分层本身却违背了“追求简单”的这个最基本设计理念。所以我们必然要在这两者上做一个折中，但是很遗憾，很多人都已经忘掉了这点，甚至觉得自己要是能够在目前成熟的架构下弄出一个说服别人的一层来是件很光荣的事情。除此之外，我还想从另一个大家很讨厌，却从始至终都摆脱不了的角度来说这第四点：哲学的角度。哲学中有这样一点：“没有完全独立的事物”，如果大家记性好应该记得在学校里，老师还拿鲁宾逊漂流记说事来着。所以从哲学的角度来说“松耦合”本身就是对哲学的挑战。而“无耦合”就是对哲学的挑衅，这是绝对不可能实现的。所以我奉劝那些战斗在“如何把耦合松一松”第一线的兄弟们，对哲学的挑战是有极限的。而任何超越这个极限的东西都是不可能实现的。所以我觉得：合理的架构 = 适当耦合度与设计简单的最佳折中，而不是一味的夸大“耦合度”或者是设计简单
------解决方案--------------------------------------------------------
牛Ｂ呀，虽然没看懂，但可以接分呀，哈哈