类设计:实体ID与实体参考 [英] Class design: entity ID vs entity reference

问题描述

如果Foo具有Bar类型的属性.两者都保存在可以通过ID检索的数据库中. (这些ID实际上是根据客户服务声明在业务范围内使用的.因此，它们不只是索引占位符.)我可以采用b1或b2所示的方法.

If I've got Foo with a property of type Bar. Both are persisted in a database which can be retrieved by an ID. (The IDs are actually used in the line of business by customer service claims. So they're not just index placeholders.) I could take the approach shown with b1 or b2.

将实体束缚在一起会使我感到恐惧，因为如果您将其推得太远，很容易弹出Null.另一方面，让ID随处显示似乎增加了不必要的冗长感.

Chaining entities together scares me since if you push that too far, it's easy to get Null's popping up. On the other hand, having the ID show up everywhere seems like it's adding unnecessary wordiness.

int fooKey = 123;
Foo f = new Foo(fooKey);
Bar b1 = new Bar(Foo.BarID);  //This?
Bar b2 = Foo.Bar;  // Or This?

注意:这与.NET实体框架无关.实体一词在一般意义上使用.

Note: This is NOT about the .NET Entity framework. The word entity is used here in the general sense.

推荐答案

通常，我会尽量避免链接，因为它通常会引入不必要的紧密耦合.一切都取决于上下文，但是就业务对象而言，保持实体之间的松散耦合是一个好主意，这样它们就可以独立增长.

As a general rule I try to avoid chaining, because it usually introduces unncessary tight coupling. All depends on the context, but in terms of business objects it might be a good idea to keep the entities loosely coupled so they can grow independently.

在您提供的示例中，我认为不存在紧密耦合的必要.我发现，如果交叉点更大，则可能有必要，但这不是企业实体的一般情况.

In the example you provide I don't think tight coupling is warranted. If the intersection was greater this might be warranted, but this isn't the general case with Business entities, I've found.

这篇关于类设计:实体ID与实体参考的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！