我有一个大型 .NET Web 应用程序。该系统有不同意图的项目(例如 CMS、论坛、电子商务)，我注意到调用另一个项目类的(天真)模式。例如，电子商务模块需要为产品动态生成文件的功能，我调用并引用 CMS 中的一个方法来执行此操作，因为文件处理实际上是 CMS 的一项工作。
显然(我知道为什么)，这是糟糕的设计和高耦合的情况。
我知道一些处理高耦合的方法，比如重组项目(虽然我真的不认为这是一个健壮的解决方案)，但是我还能做些什么来减少高耦合？有什么简单的提示吗？此外，最好知道它们为什么/如何减少耦合。我使用 .NET 3.5 和 Sql Server 2005，所以像 JMS(我在搜索有关此设计问题的提示时不断遇到)之类的东西不适用。
谢谢
顺便提一句，
我问这个的原因之一是我已经阅读了以前的类似问题，但通常如果再次问一个以前问过的问题，随着不同的人回复帖子，可以学到不同的技巧。
我知道依赖注入(inject)/IOC，但我对可以做的小事情来减少耦合感兴趣。
在决定如何减少耦合时，如何在使用静态类、接口(interface)派生类或 IOC 方法之间进行选择？此外，我可以开发一个可以调用静态类的 Web 服务 - 混合我的解决方案中的方法。
有趣的是，在我的应用程序中，我不希望它脱节。所以我只有一个论坛、电子商务系统和任何其他所需的模块，但所有内容都必须整合到一个站点中，因此每个模块(在我的 Visual Studio 解决方案中表示为一个专用项目)需要了解每个其他模块和工作用它。例如，我可能有一个处理用户配置文件的模块(使用 ASP.NET 成员资格、角色等)，但这将与论坛模块一起使用，因为论坛上的用户将是网站上的注册用户(一个始终登录)，他或她的个人资料将来自用户个人资料模块。这与我在其他网站上看到的单独配置文件相反)。
最佳答案
听起来你有一个分层问题。您的程序集应该有一个依赖循环——从最不稳定到最稳定。这使您可以明智地进行版本控制。通常，该循环类似于 UI(最不稳定)-> 域核心(稳定)-> 数据访问(最稳定)。您可以在此过程中加入实用程序或一些基础设施程序集，但同样 - 它们应该被认为比依赖于它们的程序集更稳定。
我猜你的 App.ECommerce 和 App.Cms 程序集比层更兄弟 - 所以你不希望它们相互依赖，但这并不意味着你不能重用功能。对于您的特定场景，您需要将所需的功能下推到电子商务和 Cms 都可以依赖的核心或实用程序程序集。如果它是电子商务提供的特定实现，那么您可以将接口(interface)或抽象基类推送到核心 - 并让更高层(可能是 IoC 容器)将具体的 Cms.FileCreator 类连接到 ECommerce.IFileCreator 依赖项。
关于c# - 减少耦合的简单技巧，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/311714/