我是小型IT部门的vb.net开发人员，我无法专门使用对象进行编程。
我理解OOP的原理，设计模式，单元测试等，但是在开发我的应用程序时，要么我的对象设计很差，要么我完全不使用对象构建。我知道如何创建单元测试，但对我创建的单元测试没有信心。
我几乎完全构建数据驱动的数据输入/报告类型的应用程序。在大多数情况下，许多业务逻辑都存储在存储过程和UDF的数据库中。我为内部和外部客户开发ASP.NET和Winforms应用程序。
我已经在堆栈上询问了small projects，我可以看一下，以便了解良好的设计和测试，但大多数时间都是如此。我读了很多关于设计的书。
摆脱旧的'VB 6'方式有哪些良好的第一步？
谢谢！
答案 0 :(得分：2)
一位同事让我迷上了Eric Evans的“领域驱动设计”一书。它真的开始让我在需要时摆脱数据驱动的开发。
同时参与您所在地区的.NET用户群将帮助您找到非常愿意帮助您的人。
答案 1 :(得分：1)
我听到了，伙计。我也是，活在你的世界里。商业人士需要报告的世界。复杂的报道。使用复杂的存储过程轻松构建的报告。在这个世界上，人们很容易认为数据库是王道，它驱动着应用程序。这种思路会导致复杂的数据库TSQL代码，视图，函数和存储过程。
当然，如果它确实是您需要的报告，那么复杂的SQL语句可能就是答案。但是，您想知道如何打破数据驱动的世界并进入面向对象的世界。
我认为典型的OO设计教程不会对你有所帮助。谁在乎狗是一种动物而德国牧羊犬是一种狗。这并不能解释你如何在工作中做生意。此外，这只是OO继承的一个例子。其他OO模式，如成分和依赖注入，在大多数情况下都更有用。
我认为您应该接近下一个项目或任务的方式是暂时忘记数据库。假装您生活在一个神奇的世界中，不必从数据库中获取数据，也不必将数据写回数据库。您生活在一个对象总是填充正确数据的世界中。首先在抽象世界中建模对象。在这样做之后，然后（并且只有那时）关注获取和写入数据库的混乱实现细节。数据库仅用于保存您的数据。您的数据尚未生效，因为您已将其建模为符合域规则。
理解UML对这种类型的建模有很大帮助。首先使用UML设计来为您的域建模。然后编码到那些设计。然后使用它们以适应数据库的约束。
Eric Evans“领域驱动设计”是一本很棒的书，它将这个以及许多其他相关点归结为主页。他指出，域建模是成功建模应用程序的关键因素。他接着指出，面向对象设计比任何其他类型的编程范例都更适合于域建模。 祝你好运。一旦您拥抱完全建模的完全类型的对象世界，您将永远不会再想要解析另一个数据集。答案 2 :(得分：0)
尝试从OOP aproach下开发的项目中读取代码。
想象一下，如果您将编码作为您正在阅读的示例，您的代码将会是什么样子。
坚持使用自己的代码，尝试直到你满意为止，然后当你在3个月后阅读它时，你会发现许多其他新东西需要改进它。
记住KISS规则，所有部分都适合您按照OOP原则编码。
受到纪律处分。很容易屈服于旧的方式，但不要放弃。
记住Dijstra的话： ......当你做一些快速而又肮脏的事情时，你会突然想象我正在看着你的肩膀并对自己说“Dijkstra不会喜欢这个”，嗯，这对我来说是不够的。
他住在我们每个人里面=）。你做了最重要的事情，你真的想学习如何。这是VB6开发人员改用VB.NET时的主要障碍。
看起来很熟悉？
答案 3 :(得分：0)
我建议有两件事：
答案 4 :(得分：0)
我开始只是尝试在我的日常程序编程中引入对象。然后我尝试尽可能多地从UI中获取处理。然后我尝试为我的业务逻辑和数据访问创建“层”。我知道你的很多业务逻辑可能已经存在于数据库中，但如果更改了BL层就不会有什么坏处。现在它几乎可以作为传递。
Eric Evan的领域驱动设计仍有待阅读，但有几本帮助我的书是“The Object-Oriented Thought Process”和我正在阅读的那本书，“Microsoft .NET: Architecting Applications for the Enterprise”。这本书虽然可能比你现在真正需要的还要多，但却是第一本帮助我真正理解这些层以及如何实现它们的书。
无论如何，祝你好运。请记住，这将是一个过程，而不是目的地！
答案 5 :(得分：-1)
除了其他答案中给出的建议外，你应该放弃VB.NET并学习C＃。
它不会为你做任何事情，但它会帮助你摆脱旧的思维方式。