我是否正确地表示 UML 中的依赖注入？答案

【问题标题】：Am I properly representing dependency injection in UML?我是否正确地表示 UML 中的依赖注入？
【发布时间】：2011-11-09 22:56:52
【问题描述】：

所以，我正在尝试开始使用 UML 类图，并且作为一种练习，我正在尝试对一些现有代码进行建模。假设我有这个：

public interface IDataContextWrapper : IDisposable
{
     //blah blah blah
}

public class DataContextWrapper<T> : IDataContextWrapper where T : DataContext, new()
{
     //blah blah blah
}

public class ArtistRepository
{
     L2SDCWrapper.Interfaces.IDataContextWrapper dataContext;

     public ArtistRepository()
         : this(new DataContextWrapper<ChinookDataContext>())
     {
     }

     public ArtistRepository(IDataContextWrapper dc)
     {
         dataContext = dc;
     }

     //blah blah blah
}

我想出了这个：

我的担忧：

如何正确绘制 ArtistRepository 类中的构造函数注入（我认为您会这样称呼它）？我觉得我的图表不能准确地表示它。
如何正确绘制 DataContextWrapper 的类声明？

【问题讨论】：

标签： c# uml

【解决方案1】：

尝试在 UML 中表示实现的每个细节通常不是一个好主意。 UML 更适合描述设计，据我所知，没有针对 C# 或大多数其他语言的标准化 UML 配置文件（= 改编）。

也就是说，这里有几个指针：

依赖性是相当弱的、非特定的连接。他们俩接口应通过泛化（继承）连接。
UML 允许表示泛型/模板/参数化类。对此类类建模的具体细节取决于您使用的工具。
无参数 ArtistRepository 构造函数实际上创建了一个匿名类的对象。如果您愿意，您可以在类图中表示该类，但如果您真的想了解该级别的详细信息，最好为构造函数绘制一个序列图。

这是一个类图，用 Sparx Systems 的 Enterprise Architect 绘制：

注意参数化的 DataContextWrapper 和抽象的 DataContext。它没有包含在代码示例中，但我认为它是一个抽象类；如果它实际上是一个接口，则关系应该是实现而不是泛化。

我已经对两个版本的 ArtistRepository 进行了建模，一个使用属性，另一个使用定向关联来表示 dc 成员。这两者在 UML 中是语义等价的。

我只从其中一个中提取了对 DataContextWrapper 和 ChinookDataContext 的依赖关系，但这只是为了让这个示例不会太混乱；当然，无论您选择哪种表示形式，都应该具有这两种关系。

我没有为 ArtistRepository 构造函数创建的匿名类建模。对于概述，我认为这已经足够了。

【讨论】：