我理解OOP的原理,设计模式,单元测试等,但是在开发我的应用程序时,要么我的对象设计很差,要么我完全不使用对象构建.我知道如何创建单元测试,但对我创建的单元测试没有信心.
我几乎完全构建数据驱动的数据输入/报告类型的应用程序.在大多数情况下,许多业务逻辑都存储在存储过程和UDF的数据库中.我为内部和外部客户开发ASP.NET和Winforms应用程序.
我已经在堆栈上询问了small projects,我可以看一下如何了解好的设计和测试,但是大部分时间都很短.我读了很多关于设计的书.
摆脱旧的’VB 6’方式有哪些良好的第一步？
谢谢！
我听到了,伙计.我也是,活在你的世界里.商业人士需要报告的世界.复杂的报道.使用复杂的存储过程轻松构建的报告.在这个世界上,人们很容易认为数据库是王道,它驱动着应用程序.这种思路会导致复杂的数据库TSQL代码,视图,函数和存储过程.当然,如果它确实是您需要的报告,那么复杂的SQL语句可能就是答案.但是,您想知道如何打破数据驱动的世界并进入面向对象的世界.
我认为典型的OO设计教程不会对你有所帮助.谁在乎狗是一种动物而德国牧羊犬是一种狗.这并不能解释你如何在工作中做生意.此外,这只是OO继承的一个例子.其他OO模式(如组合和依赖注入)在大多数情况下更有用.
我认为您应该接近下一个项目或任务的方式是暂时忘记数据库.假装您生活在一个神奇的世界中,不必从数据库中获取数据,也不必将数据写回数据库.您生活在一个对象总是填充正确数据的世界中.首先在抽象世界中建模对象.在这样做之后,然后(并且只有那时)关注获取和写入数据库的混乱实现细节.数据库仅用于保存您的数据.您的数据尚未生效,因为您已经将其建模以符合您的域规则.
理解UML将极大地帮助这种类型的建模.首先使用UML设计来为您的域建模.然后编码到那些设计.然后使用它们以适应数据库的约束.
埃里克埃文斯的“领域驱动设计”是一本很棒的书,它将这个以及许多其他相关点归结为家.他指出,域建模是成功建模应用程序的关键因素.他接着指出,面向对象设计比任何其他类型的编程范例都更适合于域建模.
祝好运.一旦您拥抱完全建模的完全类型的对象世界,您将永远不会再想要解析另一个数据集.