时间戳

首页 > 解决方案 > 为了避免依赖关系，是否值得创建一个相同的映射类？

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

问题描述

像 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 工具）？

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

标签： mongodboopdesign-patternsarchitecturedomain-driven-design

解决方案

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

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

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

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

推荐阅读