mongodb - 嵌套VS聚合？

Question

表示MongoDB文档的最佳方式是什么？我把 .Product作为Client.

首先，我把它们作为聚合；如果Client坏了，那Product也坏了。我是使用那个模型，还是切换到嵌套。

嵌套图示例：

Answer 1

从编程的角度来看（例如 Java）：

参考：http ://docs.oracle.com/javase/tutorial/java/javaOO/nested.html

嵌套类分为两类：静态和非静态。声明为静态的嵌套类简称为静态嵌套类。非静态嵌套类称为内部类。

class OuterClass {
    ...
    static class StaticNestedClass {
        ...
    }
    
    class InnerClass {
        ...
    }
    InnerClass innerObject = new InnerClass();
}

OuterClass.StaticNestedClass nestedObject = new OuterClass.StaticNestedClass();

从 UML 的角度来看：

1. 类从命名空间泛化

   Class--|>EncapsulatedClassifier--|>StructuredClassifier--|>Classifier--|>Namespace

2. 命名空间有“member”和“ownedMember”。

   /member : NamedElement [0..*]

   /ownedMember : 命名元素 [0..*]

   “member”代表“StaticNestedClass + InnerClass”；“ownedMember”仅代表“InnerClass”

一般建议：

1. 我不会使用“嵌套”连接器；它会在“StaticNestedClass”和“InnerClass”之间造成混淆。
2. 我不会使用“聚合”连接器（白色菱形）；因为它是由遗留原因引入的；
3. 始终使用“关联”和“组合”。

怎么做图呢？

1. 如果要对“StaticNestedClass”的元素进行建模，请将“OuterClass::StaticNestedClass”作为类名。不涉及连接器。
2. 如果要建模“InnerClass”（在 UML 规范中称为“nestedClassifier”）， (1) 在图上创建两个类元素，分别命名为“OuterClass”和“OuterClass::InnerClass”。(2) 画一个从“OuterClass”到“OuterClass::InnerClass”的“Composition”连接器。

协会或组成

这真的取决于你的要求。

大多数人喜欢从“破坏”过程来描述“构图”；“整体”被摧毁，然后“部分”也被摧毁。

但是，从“构造”过程来描述总是有效的；在你“更新整体”的过程中，你“更新了部分”。使“构造”和“销毁”它们保持一致是一种很好的做法。

例如汽车和车轮；

如果有人写了疯狂的代码，哇..

class Car{
public: 
    Wheel* w1;
    Wheel* w2;
    Car(Wheel* w1_, Wheel* w2_)
    {
        w1 = w1_;
        w2 = w2_;
    }
    ~Car()
    {
        delete w1;
        delete w2;
    }
}

Wheel* l1 = new Wheel();
Wheel* l2 = new Wheel();
Car* myCar = new Car(l1, l2);
delete myCar;
l1->Operation1();    //Crash!

所以这不是一个真正的“组合”，因为构造和破坏是不一致的。如果从析构函数中去掉“delete w1;delete w2”，那么Car和Wheel的关系就是“ Association ”。

代码的组合版本将如下所示：

class Car{
public: 
    Wheel* w1;
    Wheel* w2;
    Car()
    {
        w1 = new Wheel();
        w2 = new Wheel();
    }
    ~Car()
    {
        delete w1;
        delete w2;
    }
}