.NET, многоуровневая архитектура и MongoDB - Что использовать в качестве идентификатора?

Question

Я разрабатываю веб-службу .NET, пытаясь поддерживать многоуровневую архитектуру, которая поддерживает мои модели в одном проекте и доступ к БД (DAL) в другом. Идея заключается в том, что, если мне нужно изменить технологию БД, это просто вопрос создания DELL differnet, в то время как остальная часть приложения остается неизменной.

На уровне доступа к данным, который я разрабатываю, я использую Mongo DB C# Driver.

Я видел, что:

• Properties под названием "ID" будет отображаться на C# драйвер как "_id" в базы данных (конвенции по конфигурации);

• Int + Auto-increment in MongoDB is not a good idea;

• Использование Guid's as ID в MongoDB isn't a good idea either;

• Рекомендуемый тип данных для идентификатора документов, хранящихся в MongoDB, - ObjectID. Драйвер C# предоставляет класс для представления этого;

  • Однако, если использовать этот тип данных (от MongoDB.Bson) в моих моделях, то они становятся зависимыми от # Драйвера MongoDB C, и я не хочу, что: Я хочу, чтобы мои модели быть DB-независимым; только мои DAL могут зависеть от любых технологий доступа к данным, которые я использую.

Так какой тип данных следует использовать для идентификаторов моих Pocos' для того, чтобы иметь гарантии уникальности в БД? Будет ли строковое представление Guid быть ужасным с точки зрения производительности?

Ваш отзыв приветствуется.

Answer 1

Хороший вопрос.

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

С ObjectIds, я вижу три варианта:

• Карта между моделью домена и DAL. В модели домена вы можете использовать строковое представление objectid. Это немного раздражает, но это заставляет вас разделять проблемы.

• Используйте свой собственный тип данных и внедрите сериализатор типов/mongodb. Я этого не пробовал, но я не понимаю, почему это не сработает.

• Принять зависимость MongoDB. В конце концов, если вы действительно замените свою базу данных, это будет огромная задача. Различные базы данных имеют очень разные характеристики и требуют очень разных моделей данных.Вся «замена базы данных» через минуту - это поддельное ИМХО, это никогда не бывает так просто, а база данных - гораздо более тонкая абстракция, чем кто-либо хочет признать. Попытка сохранить независимость - это PITA. В любом случае, выполнение поиска и уничтожения на слове ObjectId будет составлять менее 1% от другой работы.