为了避免依赖关系，是否值得创建一个相同的映射类？答案

【问题标题】：Is it worth creating an identical mapping class just to avoid the dependencies?为了避免依赖关系，是否值得创建一个相同的映射类？
【发布时间】：2020-02-28 17:06:15
【问题描述】：

像 MongoDb 这样的文档数据库让您可以通过属性属性直接使用您的业务对象，如下所示。

public class Book
{
    [BsonId]
    [BsonRepresentation(BsonType.ObjectId)]
    public string Id { get; set; }

    [BsonElement("Name")]
    public string BookName { get; set; }

    public decimal Price { get; set; }

    public string Category { get; set; }

    public string Author { get; set; }
}

这里的 [BsonId] 属性指定了一个 MongoDb 主键。尽管它可以作为一种灵活性，但它非常特定于 MongoDb。现在 Book 类也变得依赖于 MongoDb 库。由于不同的项目（.net 中的项目、Java 中的包等）使用上述 Book 类，它们也变得依赖于 MongoDb 库，这反过来又打破了项目之间的松散耦合。

鉴于背景，是否值得创建一个相同的映射类来避免依赖关系（或使用 Automapper https://automapper.org 或 http://dozer.sourceforge.net/ 等 Java 工具）？

是否值得额外的管道与违反子系统松散耦合原则和单一责任原则？

【问题讨论】：

使用value object（如BookId）作为图书ID 将消除Book 类对特定底层持久层的依赖。

标签： mongodb oop design-patterns architecture domain-driven-design

【解决方案1】：

Book 类在编译时依赖于 MongoDb。但是，由于您只使用了 MongoDb 的属性，Book 在运行时不依赖于 MongoDb。

这意味着当在 CLR 中加载 Book 的目标代码时，如果没有找到 MongoDb dll，那么您将不会得到TypeLoadException。在 C#（Java 中也是如此）中，当加载时找不到定义属性的 dll 时，也不例外。找到时将选择性地加载属性 dll。

所以这意味着您可以在无法加载 MonogoDb 的环境中使用 book。您可以在不依赖 MongoDb 的情况下分发包含书籍的 dll。依赖只在编译时，如果你的代码编译，这个依赖肯定会被处理。

现在拥有一个没有属性的相同类几乎没有任何工作量太大。

【讨论】：