asp.net - SOLID 原则或无 SOLID

Question

我正在继续开发 ASP.NET 应用程序(基于 Web 表单)，其中以前的开发人员没有遵循良好的面向对象设计原则，即 SOLID (http://www.remondo.net/solid-principles-csharp-interface-segregation/)。我读过这样的帖子:Long-held, incorrect programming assumptions .

问题是很多类的内聚度低并且耦合度很高，而且很多类没有单一的职责(它们有很多)。我的具体问题是:我应该开始遵循 SOLID 原则还是只是通过 tweeking 和添加更多类(class)继续开发？我过去一直试图遵循像 SOLID 这样的原则，但我所说的应用程序非常庞大和复杂。我是唯一从事这个项目的开发人员。

目前完全重写是不可能的，但有朝一日是可能的。

2012 年 7 月 15 日更新
到目前为止，我发现 SOLID 是一种设计原则，而 GRASP 是一种设计模式，可能更适合 MVC 而不是 Page Controller 类型的应用程序。根据此链接，模拟对象也可能更适合 MVC:http://www.asp.net/mvc/tutorials/older-versions/overview/asp-net-mvc-overview .根据迄今为止的响应，遵循 SOLID 原则始终是一种很好的做法。然而，到目前为止的答案并不推荐基于表单的应用程序的设计模式。

Answer 1

尝试一点一点地重构。

如果您正在开发一个模块，请尝试在此处和那里添加一些接口(interface)；-) 随时进行。您编写的任何新代码都应该是可靠的。尝试尽可能多地封装旧代码，把旧的废话放在门面后面。您现在不必重写它，也许永远不会。只要您可以将旧代码封装在外观后面并为外观编写单元测试，您应该会感觉好多了。

示例:假设您有一组实现某些功能的类，即。发票处理。现在我想这些类在很多地方都有使用，并且有很多重复。计算总发票金额的代码被复制到显示它的每个页面上。在这种情况下，我要做的是创建一个 Invoice 服务，该服务将公开获取发票、添加新行、计算总金额等的方法。您可以将您拥有的代码放入此服务中而无需进行太多重构，您将保持相同的数据库模式等等。但从现在开始，您的页面将只与 IInvoiceService 交互。界面，你可以很好地模拟它。这有点“在地毯下扫尘”，但至少你可以阻止垃圾进一步传播。下次您需要在发票模块中做一些事情(修复错误，实现新功能)时，您可以稍微清理一下现有代码。随着时间的推移，地毯下的灰尘量越来越少。你只需要坚持你的枪，并确保服务界面保持良好和干净。

您可能需要进行更多系统范围的更改，例如引入 DI 框架，但请尽量减少更改。通常，当您开始走远时，您很容易发现自己重写了所有内容，而您不希望这样做。

做些小改动，经常提交。