- 01
 - 02
 - 03
 - 04
 - 05
 - 06
 - 07
 - 08
 - 09
 - 10
 - 11
 - 12
 - 13
 - 14
 - 15
 - 16
 - 17
 - 18
 - 19
 - 20
 - 21
 - 22
 - 23
 - 24
 - 25
 - 26
 - 27
 - 28
 - 29
 
//Невероятные приключения Microsoft'а в Индии:
        private string ExtractHttpVerb(XmlDocument configDOM)
        {
            string httpVerb;
            string hv = IfExistsExtract(configDOM, "/Config/method", "2");
            switch (hv)
            {
                case "0":
                    httpVerb = HttpVerbs[0];
                    break;
                case "1":
                    httpVerb = HttpVerbs[1];
                    break;
                case "2":
                    httpVerb = HttpVerbs[2];
                    break;
                default:
                    httpVerb = HttpVerbs[2];
                    break;
            }
            return httpVerb;
        }
                                
 Follow us!
Во вторых даже если строку, то ну еж-то в /Config/method находится число?
И вернуть уже элемент перечисления а не какую-то строку.
Говнокод тут в использовании switch.
HttpVerbs - это массив строк, метод должен вернуть одну строку из этого массива по номеру, указанному в "/Config/method".
>HttpVerbs - это массив строк
Это перечисление.
private static readonly string[] HttpVerbs = new[] { "GET", "HEAD", "POST" };
Хотя особого значения не имеет.
>вернет строку, как вы собираетесь использовать ее в качестве индекса?
Как-то так:
return HttpVerbs[index];
Только у метода parse 3 исключения возможных, плюс IndexOutOfRange, плюс возможные исключения метода ifexistextract.
Ваш, правильный код, не будет коротеньким.
Ну разве что вы пишите только для идеального случая.
Не все. что коротко - совершенно.
Бороться за строки кода - это глупость, в угоду расширяемости и отказоустойчивости.
Добавить проверки на исключения - это песня другой оперы.
Я же сказал, что говнокодом в данном случае я считаю оператор switch.
Правильный вариант:
На этот вопрос Вам ответят разработчики MS BizTalk, ибо конфиг приходит из его "интерфейса" в котором свой, отдельный, справочник вида:
{0, "GET"}, {1, "POST"}, {2, "PUT"} и так далее.
Конфиг в данном случае - это ресурс, на который мы влиять не можем.
В данном случае return IfExistsExtract(configDOM, "/Config/method", "POST");
Вернет либо строку из "/Config/method" (а это может быть "0", "1", "2"...."N"), либо строку "POST".
В первом случае - это беда-печаль.
> разработчики MS BizTalk
Мда, так вот где индусы порылись ;)
Ведь список методов, по сути, может быть тоже сторонним ресурсом. пришедшим из бездны.
В идеале метода ExtractHttpVerb должен принимать xml и IEnumerator (список методов) и работать уже с ними.
Еще более кошерно, естественно, получить в конфиге чистую строку метода, но это не всегда возможно.
Да тоже как-то топорно - не понятно, откуда брать дефолт. Хардкодить "2" или "POST" как-то некрасиво, раз уж мап теперь приходит извне. Передавать дефолт третьим параметром тоже как-то не айс.
Может быть стоит запилить отдельный универсальный класс в духе MapWithDefault, которому в конструкторе дают мап и дефолт (например добыв все это из недр бизтолка). А метод get этого класса возвращает значение из мапа, или дефолт.
Так мы избавимся от непонятного "2" и абстрагируемся от добывания этого самого мапа. А код выродится в httpVerbs.get(IfExistsExtract(configDOM, "/Config/method", "")
dictionary<string, Httpverbs> и по ключу искать, а не парсить потом исправлять кучу ошибок или кидать их дальше по слоям.
И код укоротится еще больше:
А вообще класс с таким словарем должен быть, ИМХО, я бы сделал.
Еще, кстати, интересно будет протестировать, что будет работать быстрее:
парсинг + поиск по числовому индексу в массиве
или поиск по строковому ключу словаря
Так или иначе это одна единственная ошибка, которую легко обработать.
Это совершенно не это. Нэймспэйс System.Web.Mvc не используется.
Да и по сути такого жесткого перечисления не нужно. Я использую, к примеру, только GET и POST. Остальные все убрал как и с конфига, так и из кода.