虽然将业务逻辑和数据访问逻辑分成两个不同的程序集，但我想抽象掉身份的概念，这样业务逻辑将处理一种一致的身份类型，而不必了解它在数据源中的实际表示。
由于找不到更好的术语，我一直称其为复合身份 抽象。
此项目中的数据源是可交换的、多种多样的，业务逻辑不应该关心当前正在使用哪个数据源。身份是最困难的部分，因为它的实现可以根据数据源的种类而改变，而名称、地址等其他字段始终是标量值。
我正在寻找的是一种抽象身份概念的好方法，无论它是现有的库、软件模式还是答案中提供的某种可靠的好主意。
提议的复合身份值必须在业务逻辑中具有可比性和可用性(例如作为跟踪值绑定(bind)到组合框)并传回数据源以指定要影响的记录、实体和/或文档，因此数据源必须能够解析出它自己的复合 ID 的详细信息。
数据源示例:
这有助于理解我所说的具有不同身份实现的各种数据源的含义。
一个关系数据源可能会用一个整数标识符和一个特定于语言的代码来表达一段内容。例如。
content_id language Other Columns expressing details of content 1 en_us 1 fr_ca上例中第一条记录的标识为:1 + en_us
但是，当 NoSQL 数据源 被替换时，它可能以某种方式用 GUID 字符串 936DA01F-9ABD-4d9d-80C7-02AF85C822A8 表示每条内容加上不同标准的语言代码，
第三种数据源可能只使用一个简单的标量值。
依此类推，你明白了。
最佳答案
我怀疑抽象最好用比较方法(如 IEquatable<T> 所需的方法)来表示，而不是具有属性语义的东西。
您的数据访问层最了解您的实体身份的含义，它可以返回使用适当策略实现比较的对象:您的 NoSQL 存储将返回存储和比较 GUID 的实体实现，您的关系存储将返回实体存储和比较它们的复合键等的实现。
关于c# - 抽象出复合标识值以用于业务逻辑？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5286495/