w00*_*977 5 vb.net asp.net design-principles solid-principles
我正在继续开发 ASP.NET 应用程序（基于 Web 表单），其中以前的开发人员没有遵循良好的面向对象设计原则，即 SOLID（http://www.remondo.net/solid-principles-csharp-interface-隔离/）。我读过这样的帖子：长期存在的不正确的编程假设。
问题是很多类的内聚度低，耦合度高，而且很多类没有单一的职责（它们有很多）。我的具体问题是：我应该开始遵循 SOLID 原则还是只是通过 tweeking 继续开发并向类添加更多内容？过去我一直试图遵循像SOLID这样的原则，但是我所说的应用程序非常庞大和复杂。我是唯一从事该项目的开发人员。
完全重写目前是不可能的，但总有一天是可能的。
2012 年 7 月 15 日更新 到目前为止，我发现 SOLID 是一种设计原则，而 GRASP 是一种设计模式，它可能更适合 MVC 而不是页面控制器类型的应用程序。根据此链接，模拟对象也可能更适合 MVC：http : //www.asp.net/mvc/tutorials/older-versions/overview/asp-net-mvc-overview。根据迄今为止的响应，遵循 SOLID 原则始终是一种很好的做法。但是，到目前为止的答案并不推荐基于表单的应用程序的设计模式。
尝试一点一点地重构。
如果您正在处理一个模块，请尝试随处添加一些接口 ;-)。您编写的任何新代码都应该是可靠的。尝试尽可能多地封装旧代码，将旧垃圾放在外观后面。你现在不必重写它，也许永远都不需要。只要您可以将旧代码封装在外观后面并为外观编写单元测试，您就会感觉好很多。
示例：假设您有一组实现某些功能的类，即。发票处理。现在我想这些类在很多地方都有使用，并且有很多重复。计算总发票金额的代码复制在显示它的每个页面上。在这种情况下，我会做的是创建一个 Invoice 服务，该服务将公开获取发票、添加新行、计算总金额等的方法。您可以将您拥有的代码放入此服务中，而无需进行太多重构，您将保持相同的数据库架构等等。但是从现在开始，您的页面将只与IInvoiceService界面，你可以很好地模拟它。这有点“在地毯下扫灰尘”，但至少你可以阻止垃圾进一步传播。下次您需要在发票模块中执行某些操作（修复错误，实现新功能）时，您可以稍微清理现有代码。随着时间的推移，地毯下的灰尘量会越来越小。你只需要坚持你的枪并确保服务界面保持良好和干净。
您可能需要进行更多系统范围的更改，例如引入 DI 框架，但尽量将更改保持在最低限度。通常，当您开始走得更远时，您很容易发现自己要重写所有内容，而您不希望那样。
做一些小的改变，经常提交。