Question

While separating business logic and data access logic into two different assemblies, I want to abstract away the concept of identity so the business logic will deal with one consistent identity Type without having to understand its actual representation in the data source.

I’ve been calling this a compound identity abstraction for lack of a better term.

Data sources in this project are swappable, various, and the business logic shouldn’t care which data source is currently in use. The identity is the toughest part because its implementation can change per kind of data source, whereas other fields like name, address, etc are consistently scalar values.

What I’m searching for is a good way to abstract the concept of identity, whether it be an existing library, a software pattern or just a solid good idea of some kind provided in an answer.

The proposed compound identity value would have to be comparable and usable in the business logic (e.g. bound to a combobox as the tracked value) and passed back to the data source to specify records, entities and/or documents to affect, so the data source must be able to parse back out the details of its own compound ids.

Data Source Examples:

This serves to provide an idea of what I mean by various data sources having different identity implementations.

1. A relational data source might express a piece of content with an integer identifier plus a language specific code. For example.

      content_id  language  Other Columns expressing details of content
                1  en_us
                1  fr_ca
   

   The identity of the first record in the above example is: 1 + en_us

2. However when a NoSQL data source is substituted, it might somehow represent each piece of content with a GUID string 936DA01F-9ABD-4d9d-80C7-02AF85C822A8 plus language code of a different standardization,

3. And a third kind of data source might use just a simple scalar value.

So on and so forth, you get the idea.

Answer 1

I suspect the abstraction is best represented by a comparison method (like the one required by IEquatable<T>) as opposed to something with property semantics.

Your data access layer, which knows the most about what your entity identities mean, could return objects that use appropriate strategies to implement their comparisons: your NoSQL store would return entity implementations that store and compare GUIDs, your relational store would return entity implementations that store and compare their compound keys, and so forth.