проверка массива строковых объектов на нулевые значения

Я думаю, это довольно простой вопрос, но либо мой мозг еще не проснулся, либо я просто туплю!

У меня есть класс, у которого есть свойство набора строк, определенное ниже (имена упрощены)

public class IdentifierCollection : BaseSubCollection, IIdentifierCollection
{
    public string Id1{ get; set; }
    public string Id2{ get; set; }
    public string Id3{ get; set; }
    // ...      
}

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

if (string.IsNullOrEmpty(primaryObj.Identifiers?.Id2) &&
    string.IsNullOrEmpty(primaryObj.Identifiers?.Id2) &&
    string.IsNullOrEmpty(primaryObj.Identifiers?.Id3) &&
    string.IsNullOrEmpty(primaryObj.Identifiers?.Id4) &&
    string.IsNullOrEmpty(primaryObj.Identifiers?.Id5) &&
    string.IsNullOrEmpty(primaryObj.Identifiers?.Id6) &&
    string.IsNullOrEmpty(primaryObj.Identifiers?.Id7) &&
    string.IsNullOrEmpty(primaryObj.Identifiers?.Id8))
{

}

Просто напечатать это кажется неправильным!! Должен быть лучший способ...


null-check c#
person dreadeddev    schedule 25.02.2016    source источник
comment
Почему у вас нумерованные свойства? Почему бы не использовать словарь или список? Однако вы можете использовать отражение, чтобы найти и проверить свойства, если вы не можете их потерять.   -  person CodeCaster    schedule 25.02.2016
comment
@CodeCaster Мне интересно, является ли это эффектом (упрощенные имена). Если нет, то вполне может быть совсем другой ответ на вопрос, то есть то, что вы предлагаете...   -  person James Thorpe    schedule 25.02.2016
comment
Да, настоящие имена - это то, над чем я работаю, и это смутно конфиденциально.   -  person dreadeddev    schedule 25.02.2016
comment
Но использование отражения будет дороже, чем просто уродливый код... или нет?   -  person dreadeddev    schedule 25.02.2016
comment
Вы действительно получаете доступ к этим свойствам по имени где-то, или словарь все еще вариант? И определить дорогой. Да, отражение относительно медленное, но оно поддерживается средой выполнения, кэширующей различные объекты.   -  person CodeCaster    schedule 25.02.2016
comment
Если IIdentifierCollection намекает, что это коллекция, почему она не реализует IEnumerable? Затем вы можете просто перебрать его с помощью foreach или чего-то еще.   -  person Neijwiert    schedule 25.02.2016
comment
Да, они используются и составляют объекты Poco и JSON, которые затем сохраняются в DocumentDb.   -  person dreadeddev    schedule 25.02.2016
comment
Это может быть лучшим решением @Neijwiert ... попробую сейчас, не стесняйтесь добавлять его в качестве ответа!   -  person dreadeddev    schedule 25.02.2016
comment
И если это не просто чистая строка, вы можете сделать IEnumerable‹Object›, а затем foreach (идентификатор объекта в theidentifierobject) { if (идентификатор как String! = null) { blah blah   -  person Neijwiert    schedule 25.02.2016
comment
@Neijwiert, помня о том, что OP хочет сохранить там свойства: как вы можете перебирать отдельный класс со свойствами? Вы можете создать перечислитель, который выполняет итерацию по свойствам и возвращает их значения, но тогда вы вернетесь к исходной точке.   -  person CodeCaster    schedule 25.02.2016
comment
Сколько раз вы вызываете этот метод (проверяя, что любое из свойств имеет значение null) и сколько таких объектов у вас есть? Существуют ли различные типы конфигураций: например. проверка только некоторых свойств, являющихся нулевыми, на основе некоторых критериев и т. д.?   -  person Tamas Ionut    schedule 25.02.2016
comment
@CodeCaster Я не вижу другого «чистого» решения. Если они являются отдельными переменными-членами. Отражение не кажется мне чистым. Если вы заставите кодировщик реализовать итератор, он будет работать для каждого вновь созданного класса, который реализует IIdentifierCollection.   -  person Neijwiert    schedule 25.02.2016
comment
@Neijwiert не кажется чистым, это мнение. Рефлексия более надежна, чем написанный вручную перечислитель, который содержит только yield return Id1; yield return Id2; и так далее, потому что он подвержен ошибкам.   -  person CodeCaster    schedule 25.02.2016

Ответы (1)


arrow_upward
1
arrow_downward

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

if (NoPropIsNullOrEmpty())
{
}

private bool NoPropIsNullOrEmpty()
{
    return !(string.IsNullOrEmpty(primaryObj.Identifiers?.Id2) ||
             string.IsNullOrEmpty(primaryObj.Identifiers?.Id2) ||
             string.IsNullOrEmpty(primaryObj.Identifiers?.Id3) ||
             string.IsNullOrEmpty(primaryObj.Identifiers?.Id4) ||
             string.IsNullOrEmpty(primaryObj.Identifiers?.Id5) ||
             string.IsNullOrEmpty(primaryObj.Identifiers?.Id6) ||
             string.IsNullOrEmpty(primaryObj.Identifiers?.Id7) ||
             string.IsNullOrEmpty(primaryObj.Identifiers?.Id8));
}
person Kapol    schedule 25.02.2016
comment
Я склонен согласиться, BaseCollection действительно реализует индексатор, так что я могу получить доступ к свойствам, как если бы они были массивом, поэтому IEnumerable имел смысл, но в конечном итоге это было излишним, чтобы избежать нескольких уродливых строк кода... Я я уже использовал вспомогательный метод, так что я просто слишком придирчив!!! - person dreadeddev; 25.02.2016
comment
Я не думаю, что в такой проверке свойств есть что-то неправильное - это копипастный код, так что со всеми его недостатками. - person CodeCaster; 25.02.2016