Мой коллега и я обсуждаем, какой из этих методов следует использовать для автоматического создания идентификатора пользователя и идентификатора сообщения для идентификации в базе данных:
Один вариант использует один экземпляр Random и принимает некоторые полезные параметры, поэтому его можно повторно использовать для всех видов строковых (например, от четырехзначных цифровых контактов до 20-значных буквенно-цифровых идентификаторов). Здесь код:
// This is created once for the lifetime of the server instance
class RandomStringGenerator
{
public const string ALPHANUMERIC_CAPS = "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890";
public const string ALPHA_CAPS = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
public const string NUMERIC = "1234567890";
Random rand = new Random();
public string GetRandomString(int length, params char[] chars)
{
string s = "";
for (int i = 0; i < length; i++)
s += chars[rand.Next() % chars.Length];
return s;
}
}
а другой вариант - просто:
Guid.NewGuid();
Мы оба знаем, что Guid.NewGuid() будет работать для наших нужд, но я предпочел бы использовать собственный метод. Он делает то же самое, но с большим контролем.
Мой коллега полагает, что, поскольку пользовательский метод был приготовлен самостоятельно, он, скорее всего, создаст столкновения. Я признаю, что не знаю о реализации Random, но я предполагаю, что он так же случайен, как Guid.NewGuid(). Типичным использованием настраиваемого метода может быть:
RandomStringGenerator stringGen = new RandomStringGenerator();
string id = stringGen.GetRandomString(20, RandomStringGenerator.ALPHANUMERIC_CAPS.ToCharArray());
Изменить 1:
- Мы используем Azure Tables, который не имеет функции автоматического увеличения (или аналогичного) для генерации ключей.
- Некоторые ответы здесь просто говорят мне использовать NewGuid() ", потому что это то, что он сделал для". Я ищу более глубокую причину того, почему метод варки может с большей вероятностью генерировать коллизии при одинаковых степенях свободы, как Guid.
Изменить 2:
Мы также использовали метод cooked для генерации идентификатора сообщения, который, в отличие от токенов сеанса, должен выглядеть красиво для отображения в URL-адресе нашего веб-сайта (например http://mywebsite.com/14983336), поэтому здесь нет выбора, но конфликтов все равно следует избегать.
