Я не думаю, что для этого есть конкретная модель.
Это хорошая практика?Я так не думаю.Во-первых, он не очень объектно-ориентирован.Как насчет:
interface ICommittable
{
/// <summary>
/// Gets or sets a value indicating whether the entity was already committed to the database.
/// </summary>
bool IsCommitted;
/// <summary>
/// Gets or sets the ID of the entity, used either in database or generated by UI or an underlying BL.
/// </summary>
Guid Id;
}
Вместо этого они смешивают три отдельные записи данных в одну неочевидным образом:
- ID
- Другой идентификатор (почему?)
- Факт, что объект был зафиксирован или нет.
Особенно наличие двух отдельных идентификаторов крайне запутанно и потребует не толькохорошая документация, но некоторое время для нового разработчика, чтобы понять, что здесь происходит.
Если цель состояла в том, чтобы создавать новые объекты без запроса базы данных для нового идентификатора, они могли бы использовать GUID везде: когда новый объектсоздается, вы Guid.CreateNew это ID, затем, если нужно, вы фиксируете все, этот GUID также является идентификатором в базе данных (существует небольшая вероятность столкновения между уже сохраненными GUID и новым, так что я бы не сталвсе равно).
Гораздо проще, не правда ли?
Нелегко сделать несколько вещей.Например, как вы сравниваете две сущности?Помните, что:
- Два подтвержденных объекта с разными идентификаторами GUID не равны,
- Два не подтвержденных объекта с разными идентификаторами не равны,
- Подтвержденный объектможет быть равным необязательному объекту, даже если их GUID и их идентификаторы будут отличаться.
В заключение, выглядит такотсутствие рефакторинга .Вероятно, они модифицировали проект, в котором сущности уже были идентифицированы в базе данных по их уникальному ключу id (int), поэтому вместо рефакторинга они просто добавили GUID, что в целом усложнило:
- Более сложночтобы понять,
- Очень трудно работать и изменять в будущем.