实体标识 - 使用字符串而不是类型 [英] Entity Identity - use of strings instead of type
问题描述
我看过许多 DDD 帖子和书籍，其中实体类派生自某种形式的基类，这些基类具有实体标识类型的通用参数:
I have seen a number of DDD posts and indeed books where entity classes are derived from some form of base class that has a generic parameter for the Entity Identity type:
public interface IEntity<out TKey>
{
TKey Id { get; }
}
public interface IComplexEntity<out TKey, in TEntity>
{
TKey Id { get; }
bool IsSameAs(TEntity entity);
}
//Object Definition
public class TaxPayer : IComplexEntity<string, User>
{
...
}
在 Vernon 的实现领域驱动设计中，创建了特定类型以用作身份:
On Vernon's Implementing Domain Driven design, specific types are created for use as identities:
public class TaxPayerIdentity : Identity
{
public TaxPayerIdentity() { }
public TaxPayerIdentity(string id)
: base(id)
{
}
}
最近我一直致力于将事件总线上的事件传达给外部侦听器.我的问题"是我需要一个通用的消息格式来发送事件信封:
More recently I have been working on communicating events on an event bus to external listeners. The "issue" I have is I need a common message format for sending of the event envelope:
public EventEnvelope
{
long EventStoreSequence; // from the event store
bool IsReplay; // if event store is replaying from position 0 of stream
object EventBeingSent; // this is the actual event, i.e. class AddressChanged { string Old; string New; DateTime On; }
object IdentityOfSender; // this is the identity of the entity who raised the event
}
IdentityOfSender 上面是一个对象，但实际值是string、int、Guid 等取决于对象标识类型.
Above the IdentityOfSender is an object, but the actual value would be string, int, Guid etc depending on the objects identity type.
我的问题是为什么不简单地使用字符串作为身份?毕竟，Guids、整数、名称、数字都可以表示为字符串，并且它们很容易与通用格式的字符串进行比较——这不仅会使 EventEnvelope 使用字符串作为通用格式更容易，而且会使实体更容易处理而不需要基类或特殊类型?
My question is why not simply use a string for the identity? After all, Guids, integer, names, numbers can all be represented as strings and they are easily comparable as strings in a common format - this not only would make the EventEnvelope easier with a string as a common format, it would make Entities easier to handle without need for base classes or special types?
总之，为什么人们不推荐使用字符串作为身份的通用格式(或者我没有见过)，而是谈论身份的基类和泛型类型?
推荐答案
因为跨文化字符集中的字符串比较并不容易.可以与字符串进行比较的最接近的数据类型是 GUID.但即使是 GUID 也可以有不同的字符串表示.
Because string comparison in cross-culture charset is not easy. The closest data type that can be compared with string is GUID. But even GUID can have different string representation.
例如:
{FD49D6AE-019C-4118-B7D1-A4DA54E4474F},
fd49d6ae-019c-4118-b7d1-a4da54e4474f,
FD49D6AE019C4118B7D1A4DA54E4474F
所有三个都具有相同的 GUID 值但不同的字符串比较.Number 因千位分隔符/小数点格式差异而闻名.
All three have same GUID value but different string comparison. Number is famous for the thousand separator / decimal point format difference.
而且，我认为为身份定制的类是为了提供明确的身份比较.示例:信用卡卡号的前六位有一个六位发卡行标识号 (IIN) (维基百科).也就是说，使您在领域驱动设计中具有更高的灵活性.是的，这种设计使您无法使用一劳永逸"的数据类型.
Moreover, I believe that the custom class for identity is to provide explicit identity comparison. Example: Credit card number's has a six-digit Issuer Identification Number (IIN) in the first six digit (wikipedia). That is, enable you higher flexibility in domain-driven design. And yes, that design prevent you from using "one for all" data type.
但是，您可以通过对象映射为外部总线使用编码-解码模型.这样您就可以避免破坏 DDD，同时在整个外部总线上提供相同的格式.
However you can use encode-decode model for external bus through object mapping though. That way you can avoid breaking the DDD and at the same time providing same format throughout external buses.
除此之外，这是一个通用指南.软件工程中的每一个指南都有利有弊.使用您认为最合适和最了解的一种，但在整个设计中保持一致.
That aside, it is a general guidelines. And every guidelines in software engineering has pros and cons. Use one you find most suitable and know the best, but keep it consistent across your design.
这篇关于实体标识 - 使用字符串而不是类型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
