Абстрагироваться от сложного значения идентичности для использования в бизнес-логике?

Question

Разделяя бизнес-логику и логику доступа к данным на две разные сборки, я хочу абстрагироваться от концепции идентичности, чтобы бизнес-логика работала с одним непротиворечивым типом идентичности без необходимости понимать его фактическое представление в источнике данных.

Я назвал это составной идентичностью абстракцией из-за отсутствия лучшего термина.

Источники данных в этом проекте могут быть заменены, они различны, и бизнес-логике должно быть все равно, какой источник данных используется в настоящее время. Идентификация - самая сложная часть, потому что ее реализация может меняться в зависимости от вида источника данных, тогда как другие поля, такие как имя, адрес и т. Д., Являются последовательно скалярными значениями.

То, что я ищу, - это хороший способ абстрагировать понятие идентичности, будь то существующая библиотека, шаблон программного обеспечения или просто хорошая идея какого-то рода, приведенная в ответе.

Предлагаемое составное значение идентификатора должно быть сопоставимым и использоваться в бизнес-логике (например, привязываться к комбинированному списку в качестве отслеживаемого значения) и передаваться обратно в источник данных, чтобы указать записи, сущности и / или документы, на которые нужно воздействовать, поэтому источник данных должен иметь возможность анализировать детали своих составных идентификаторов.

Примеры источников данных:

Это дает представление о том, что я имею в виду под различными источниками данных, имеющими разные реализации идентичности.

1. A реляционный источник данных может выражать фрагмент содержимого с целочисленным идентификатором плюс код для конкретного языка. Например.

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

   Идентификатор первой записи в приведенном выше примере: 1 + en_us

2. Однако, когда подставляется NoSQL источник данных , он может каким-то образом представлять каждый фрагмент контента строкой GUID 936DA01F-9ABD-4d9d-80C7-02AF85C822A8 с добавленным языком код другой стандартизации,

3. И третий тип источника данных может использовать просто простое скалярное значение.

Так и так далее, вы поняли идею.

Answer 1

Я подозреваю, что абстракция лучше всего представлена ​​в виде сравнения метод (как тот, который требуется для IEquatable<T>), в отличие от чего-то с семантикой свойств.

Ваш уровень доступа к данным, который знает больше всего о том, что означают ваши сущности, может возвращать объекты, которые используют соответствующие стратегии для осуществления своих сравнений: ваше хранилище NoSQL будет возвращать реализации сущностей, которые хранят и сравнивать GUID, ваше реляционное хранилище будет возвращать реализации сущностей, которые храняти сравните их составные ключи и так далее.

Answer 2

Будет ли работать dynamic тип для вас?

Я думаю, что он будет работать до тех пор, пока вы не назначите идентификаторы на уровне пользовательского интерфейса / бизнес-логики.Сравнение должно работать.