C#循环依赖解题技术答案

【问题标题】：C# Circular Dependency Problemsolving TechniqueC#循环依赖解题技术
【发布时间】：2009-09-12 17:57:42
【问题描述】：

在将我的 C# 应用程序分层时，我通过以下方式解决了层之间的循环依赖问题：

using System;
using System.Collections.Generic;
using System.Text;

using SolvingCircularDependency.Common;
using SolvingCircularDependency.DA;

namespace SolvingCircularDependency.BO
{
    public class MyClass : IPersistent
    {
        private string _message;
        public string Message
        {
            get { return _message; }
            set { _message = value; }
        }

        public bool Save()
        {
             return MyClassDA.Save(this);
        }
    }
}


using System;
using System.Collections.Generic;
using System.Text;

namespace SolvingCircularDependency.Common
{
    public interface IPersistent
    {        
        bool Save();
        string Message { get;}
    }
}

using System;
using System.Collections.Generic;
using System.Text;

using SolvingCircularDependency.Common;

namespace SolvingCircularDependency.DA
{
    public class MyClassDA
    {
        public static bool Save(IPersistent obj)
        {
            Console.WriteLine(obj.Message);

            return true;
        }
    }
}

using System;
using System.Collections.Generic;
using System.Text;

using SolvingCircularDependency.BO;

namespace SolvingCircularDependency.UI
{
    class Program
    {
        static void Main(string[] args)
        {
            MyClass myobj = new MyClass();
            myobj.Message = "Goodbye Circular Dependency!";
            myobj.Save();

            Console.ReadLine();
        }
    }
}

谁能建议我更好的解决方案，因为 sln 中的“Common”项目对我来说是多余的？

【问题讨论】：

标签： c# .net circular-dependency

【解决方案1】：

由您决定是否应在 Common 或 Service 程序集中声明 IPersistent。最佳实践（通常）是在单独的程序集中声明接口以实现更好的层分离。您需要考虑开发人员创建 IPersistent 实现的频率、是否真的需要松散耦合等。

【讨论】：

服务组装是什么意思？
再次抱歉，我认为我的上一个答案可能不明显。我认为 Common 是一个不依赖于其他程序集（您自己的程序集）的程序集。如果为真，则表示该程序集是托管 IPersistent 接口的良好候选者。

【解决方案2】：

请注意依赖倒置原则。

【讨论】：

是的，DI 是我们处理服务/接口问题时的常见情况。
如何使用 DI 重写这个程序？
不，请不要。我的意思是，如果你这样问问题。 DI 意味着“松散耦合”，在现实生活中很少需要（如果使用不当，它会增加令人难以置信的配置地狱）。
@frogbot 什么？ “松散耦合”是一个很好的设计原则，我再说一遍，应该永远追求。不尝试实现松散耦合将导致依赖于大量事物的高度重复的代码。这意味着您对系统所做的每项更改现在都会影响越来越多的类，从而导致越来越多的错误。它很快成为维护的噩梦。
我认为您的 IPersistent 界面中有混合。它似乎至少有两个消费者 - DA 类访问数据属性（如消息）和某人（如果存在，则此处未显示）使用 IPersistent.Save() 因为从 DA 类中使用它似乎没有意义。因此，一旦您将它们与职责分开，您就可以继续重构您的解决方案。接下来，您需要确定要重用的部分，从而使其依赖关系变弱 - 将 IPersistent 接口放在单独的程序集中（分离接口原则）或将其放入可重用类的程序集中。

【解决方案3】：

IPersistence 是您 DA 关心的问题，也是您的 BO 通过它进行交流的一种方式。这种关系应该到此为止。您的 UI 应该只知道您的 BO，如果您需要定义一个新接口来支持“编码到合同”，请在您的 BO 中定义一个新接口。您的 UI 和 BO 应该分别关注他们在系统中所做的事情。

例如，IPersistence 接口将定义将记录持久保存到数据库的特定任务。您不希望在您的 UI 中使用它，因为它会绕过您的 BO。所以除非你想要一个虚弱的 BO，它真的什么都不做，根本不应该在那里，否则在那个级别定义一些与支持你的业务逻辑相关的新东西。

【讨论】：