5

我正在继续开发 ASP.NET 应用程序（基于 Web 表单），其中以前的开发人员没有遵循良好的面向对象设计原则，即 SOLID（http://www.remondo.net/solid-principles-csharp-interface-隔离/）。我读过这样的帖子：长期持有的、不正确的编程假设。

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

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

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

4

4 回答 4

5

尝试一点一点地重构。

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

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

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

做些小改动，经常提交。

于 2012-07-14T18:09:04.677 回答
0

这就像在问“嗯，我刚从别人那里买了一套公寓，但到处都是脏东西。我应该把它清理干净还是让它保持原样？”

答案很明显。你说应用程序很复杂。如果它只是因为糟糕的架构而变得复杂 - 你有机会让它更容易理解。由于业务问题的性质，它很复杂，糟糕的架构只会让情况变得更糟。

SOLID 是非常重要的原则。还要注意 GRASP 指南，我猜你这样做是因为你提到了低耦合和高内聚，这些属于 GRASP 而不是 SOLID。

最明显的方法是重构，朝着正确的方向一步一步地进行。解耦类，定义它们的职责，使它们更具凝聚力，引入接口和针对它们的代码。这些比 SOLID 的开闭原则或 Liskov 替换原则重要得多。

于 2012-07-14T19:42:38.743 回答
0

我的建议是选择一个功能并开始对其进行单元测试并引入一个模拟库，例如 Moq 或 FakeItEasy。

我完全理解这是给你的代码。但是通过单元测试，您将了解哪些代码适合单一职责或必须是服务或必须移动到存储库中。

您已经打算实现 DI，但也使用 AutoMapper 之类的东西可以节省大量时间并使代码更小更清晰

当我像你的情况一样被移交时，我所做的就是阅读鲍勃叔叔的书http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052它给了你一些好处想法

更新您的评论： 前 3 个月后的应用程序有更少的错误，并且更容易和更快地实施新的更改。最好的部分是现在我们拥有了领域知识。阻止导致错误的遗留和新更改的一件好事是 Anit-Corruption 层请阅读此链接http://domaindrivendesign.org/library/peng_hu_2007_2

于 2012-07-14T20:19:21.923 回答
0

我曾在一家拥有良好单元测试代码覆盖率（超过 3000 次测试）的商店工作，其编写鼓励我们的代码通常遵循 SOLID 原则。

我还在一家代码覆盖率为 0%（大约 0.5m 行代码）的商店工作过，它丝毫没有采用 SOLID。

我们无法重构任何 50 万行代码（出于 SOLID 或任何其他原因），因为我们没有测试覆盖率。因此，随着时间的推移，代码变得越来越难以维护。

在我的第一份工作中我们不需要重构，因为代码已经是 SOLID，但我们可以轻松地重构并使用良好的单元测试代码覆盖率来确保没有回归。

这就像魔术：对于那些相信不需要证据的人来说；对于那些不相信任何证据都不够的人。

让我们这样说吧：你想在某个地方工作，代码非常难以理解，维护起来很糟糕，开发人员因为代码太差而离开，错误猖獗，或者你更喜欢相反的地方？后者的代码，无论是否 SOLID，但恕我直言，带有单元测试的 SOLID 从长远来看将使实现这一目标变得更加容易。

于 2016-07-29T23:29:57.793 回答