2014-09-19 2 views
3

У меня есть слой данных (содержит соединение с MongoDB), слой домена (содержит операции РЕПО и юридические лица) и слой услуг (содержит услуги и модели)MongoDB ObjectIds экспозиции

Теперь, потому что мои предприятия используют ObjectIds, они требуют знание MongoDB (это прекрасно?)

Мои сервисы получают вызовы репозиториев, которые возвращают эти сущности, а затем преобразуют их в модели. Это приводит к тому, что мой уровень обслуживания требует знания MongoDB из-за свойства ObjectId на объектах.

Есть ли способ избежать этого? Я слышал, что могу использовать строку типа Id как типа, а при хранении данных MongoDB преобразует это в ObjectId?

ответ

1

Иногда при сопоставлении только идентификатор может сбивать с толку, а также то, что происходит в случае, если у вас может быть другой объектId (возможно, ссылка) в одном и том же объекте?

хорошо вы можете сделать карту для объектаИспользуйте карту convention over configuration pattern. посмотреть на следующую реализации:

public static class MongoDbConventionRegistry 
{ 
    public static void Register() 
    { 
     var conventionPack = new ConventionPack {new StringObjectIdMemberMapConvention()};    
     ConventionRegistry.Register("CustomConventions", conventionPack, t => t.FullName.StartsWith("YourNamespace.Model.Entities.etc")); 
    } 

} 

public class StringObjectIdMemberMapConvention : IMemberMapConvention 
{ 
    private readonly Regex _memberMatchRegex = new Regex(@"(^Id$)|(.+ObjectId?$)",RegexOptions.Compiled); // you can change this regex to match the convention you want 

    public string Name { 
      get { return "StringObjectId"; } 
     } 

     public void Apply(BsonMemberMap memberMap) 
     { 
      if (memberMap == null) 
       return; 
      if(memberMap.MemberType == typeof(string) && _memberMatchRegex.IsMatch(memberMap.ElementName)) 
       memberMap.SetRepresentation(BsonType.ObjectId); 
     } 

    } 

так в этом случае любого Id и любое другое имущество, которое заканчивается ObjectId будет отображаться в ObjectId, так что вы можете оставить свои Entities идентификаторов в виде строки, и водитель будет обрабатывать преобразования для вам, это удобнее, когда вы не хотите нести зависимости mongodb между большинством ваших слоев в вашей системе.

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

3

Краткая версия: да, используйте строку везде.

Если вы нормально с аннотациями, а затем использовать:

[BsonId] 
[BsonRepresentation(BsonType.ObjectId)] 
public string Id { get; set; } 

В противном случае вы можете использовать карту класса:

BsonClassMap.RegisterClassMap<i_YourModel>(cm => 
{ 
    cm.AutoMap(); 
    cm.SetIdMember(cm.GetMemberMap(x => x.Id) 
    .SetIdGenerator(StringObjectIdGenerator.Instance)); 
} 
); 

Длинная версия:

Рекомендуется использовать что-то непрозрачный , который напрямую не связан с базовой реализацией базы данных в вашей модели и уровне обслуживания (насколько это возможно).

Ранее первичные ключи, где обычно большие числа, которые затем были сопоставлены с номером первичного столбца ключа в базе данных. Однако при назначении нового идентификатора новому объекту необходимо проверить проверку базы данных, чтобы обеспечить уникальный идентификатор. Существует множество методов, из генераторов LO-HI, для столбцов auto_increment, для последовательностей и т. Д.

С NoSQL и необходимостью большего параллелизма большинство приложений теперь используют UUID или его варианты, поскольку идентификатор может быть генерируемый с разумными вероятностями, он будет уникальным, без необходимости запрашивать базу данных, если он действительно уникален или использует последовательности или тому подобное, которые являются узкими местами в приложении, которое масштабируется горизонтально.

MongoDB не имеет значения и использует ObjectId, которые являются своего рода UUID.

Эти идентификаторы (как mongo, так и другие) всегда могут быть представлены как строки, обычно HEX-представление байтов, составляющих ключ. Таким образом, в вашей модели используйте String как идентификаторы, на вашем уровне обслуживания, то же самое, в вашем слое данных конвертируйте его в любой формат для вашей базовой реализации базы данных, MongoDB в этом случае.

+0

Итак, у моего UserModel будет строка UserId, и у моего UserEntity также будет строка UserId? Или это еще нужно знать MongoDb и использовать ObjectId для объекта – Luke

+0

Пробовал пояснить ответ. –

Смежные вопросы