Этот консультант ASP.NET знает то, что он делает?

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

Этот весь поток ответа полон типичных отношений программиста. Это напоминает мне о статье 'Things you should never do' Joel (перепишите с нуля.) Мы ничего действительно не знаем о системе, кроме существует ошибка, и некоторый парень разместил некоторый код в Интернете. Существует столько неизвестных, что смешно сказать, что "Этот парень не знает то, что он делает".

Если консультанты развернули свое приложение ASP.NET на Вашем сервере (серверах), то они, возможно, развернули его в нескомпилированной форме, что означает, что был бы набор *.cs файлов, плавающих, вокруг которого Вы могли посмотреть на.

Если все, что можно найти, является скомпилированными блоками.NET (DLLs и EXEs) их, то необходимо все еще смочь декомпилировать их в несколько читаемый исходный код. Я буду держать пари, просматриваете ли Вы код, Вы найдете их использующий статические переменные в их собственном коде поиска. У Вас затем было бы что-то очень конкретным, чтобы показать Вашим боссам.

Вещь сессии возможна. Это - ошибка, вне сомнения, но могло случиться так, что запись прибывает в любого пользовательского поставщика состояния сеанса, которого Вы используете после следующего чтения. Поставщик состояния сеанса API размещает блокировку для предотвращения этого вида вещи, но если конструктор только что проигнорировал все это, консультант, мог бы говорить правду.

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

Если SomeProprietarySessionManagementLookup (); делает асинхронное присвоение, оно было бы более вероятно похоже на это:

SomeProprietarySessionManagementLookup(Session["UserID"]);

Самое то, что код присваивает результат Сессии ["Идентификатор пользователя"], предположило бы, что это, как предполагается, не является асинхронным, и результат должен быть получен перед Ответом. Перенаправление называют. Если SomeProprietarySessionManagementLookup возвращается, прежде чем его результат будет вычислен, у них есть недостаток дизайна так или иначе.

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

Я предполагаю, что Ваш консультант предлагает, используют переменную состояния вместо исключения для обработки ошибок, лучшая практика? Я не соглашаюсь. То, как часто делает людей, забыло или слишком ленивый, чтобы сделать проверку ошибок на возвращаемые значения? Кроме того, переменная передачи/сбоя является весьма формирующей. Существует больше вещей, может пойти не так, как надо кроме деления нулем как целое число x/y, является слишком большим, или x является NaN. Когда вещи идут не так, как надо, переменная состояния не может сказать Вам, что пошло не так, как надо, но исключение может. Исключение для исключительного случая, и разделитесь на нуль, или NaN являются определенно исключительными случаями.

Типичные яйца "консультанта":

1. Проблема с любым SomeProprietarySessionManagementLookup, делает
2. Исключения являются только дорогими, если они брошены. Не бойтесь try..catch, но броски должны только произойти при исключительных обстоятельствах. Если переменная y не должен быть нуль затем ArgumentOutOfRangeException было бы соответствующим.

Довольно странный. На втором объекте это может или не может быть быстрее. Это, конечно, не та же функциональность все же.

Я должен согласиться с John Rudy. Мой пищеварительный тракт говорит мне, что проблема находится в SomeProprietarySessionManagementLookup ().

.. и Ваши консультанты не звучат верным из себя.

Хранение на Сессии в не асинхронный. Таким образом, это не верно, если та функция не асинхронна. Но несмотря на это, так как это не называет BeginCall и имеет что-то для обращения к завершению, следующая строка кода не выполнилась бы, пока строка Сессии не завершена.

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

Я не думаю, что это - твердое предложение вообще.

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

Асинхронный ответ походит на БАКАЛАВРА НАУК, но может быть что-то в нем. По-видимому, они предложили подходящее решение, а также псевдокод, описывающий проблему, которую они сами создали. Я больше испытал бы желание судить их на их решении, а не их выражении проблемы. Если их понимание будет испорчено, то их новое решение не будет работать также. Затем Вы будете знать, что они - идиоты. (На самом деле оглянитесь, чтобы видеть, есть ли у Вас уже подобное доказательство в каких-либо других областях их кода),

Другой является проблемой стиля кода. Существует много различных способов справиться с этим. Мне лично не нравится тот стиль, но будут обстоятельства, при которых это подходит.

Они неправы в асинхронном.

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

Они неправы в том защитном стиле кодирования в любом коде низкого уровня и даже в высокоуровневой функции, если это не определенная экономическая модель, что 0 или Пустая или пустая строка или независимо от того, что должно быть обработано тот путь - в этом случае, это всегда успешно (что успешный флаг является противным запахом кода), и не исключение. Исключения для исключений. Вы не хотите маскировать поведения как это путем потворства с вызывающими сторонами функций. Вещи выгоды рано и выдают исключения. Я думаю, что Maguire покрыл это в записи Основательного Кода или McConnell в Завершенном Коде. Так или иначе это пахнет.

Эмпирическое правило Cody не ошибается. Если необходимо спросить, он, вероятно, не делает.

Это походит на точку два ее очевидно неправильный. стандарты.NET объясняют, что, если метод перестал работать, он должен выдать исключение, которое кажется ближе к оригиналу; не предложение consulstant. Принятие исключения точно и конкретно описывает отказ.

Для первой точки, которая действительно кажется причудливой.

На втором разумно стараться избегать подразделения 0 - это совершенно преодолимо, и то предотвращение просто. Однако использование параметр для указания на успех только разумно в определенных случаях, таково как интервал. TryParse и DateTime. TryParseExact - где вызывающая сторона не может легко определить, разумны ли их аргументы. Даже затем возвращаемое значение обычно является успехом/отказом и, параметр является результатом метода.

Сессии Asp.net при использовании встроенных поставщиков случайно не дадут Вам чужую сессию. SomeProprietarySessionManagementLookup() вероятный преступник и возвращает плохие значения или просто не работает.

Session["UserID"] = SomeProprietarySessionManagementLookup();

В первую очередь, присваивая возвращаемое значение от асинхронно SomeProprietarySessionManagementLookup () просто работа привычки. Консультанты кодируют, вероятно, похож:

public void SomeProprietarySessionManagementLookup()
{
    // do some async lookup
    Action<object> d = delegate(object val)
    {
        LookupSession(); // long running thing that looks up the user.
        Session["UserID"] = 1234; // Setting session manually
    };

    d.BeginInvoke(null,null,null);               
}

Консультант не полностью полон БАКАЛАВРА НАУК, но они написали некоторый содержащий код. Ответ. Перенаправление () действительно бросает ThreadAbort, и если собственный метод является асинхронным, asp.net не знает для ожидания асинхронного метода записать обратно к сессии, прежде чем asp.net самой сохранит сессию. Это, вероятно, почему это иногда работает и иногда не делает.

Их код мог бы работать, если сессия asp.net в процессе, но сервер состояния или сервер дб не были бы. Это синхронизирует зависимого.

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

Action<object> d = delegate(object val)
{
    System.Threading.Thread.Sleep(1000);  // waits a little
    Session["rubbish"] = DateTime.Now;
};

d.BeginInvoke(null, null, null);
System.Threading.Thread.Sleep(5000);      // waits a lot

object stuff = Session["rubbish"];
if( stuff == null ) stuff = "not there";
divStuff.InnerHtml = Convert.ToString(stuff);

Этот следующий отрывок кода не работает, потому что сессия была уже сохранена назад для утверждения сервера к тому времени, когда асинхронный метод находит время для устанавливания значения сессии.

Action<object> d = delegate(object val)
{
    System.Threading.Thread.Sleep(5000);  // waits a lot
    Session["rubbish"] = DateTime.Now;
};

d.BeginInvoke(null, null, null);

// wait removed - ends immediately.
object stuff = Session["rubbish"];
if( stuff == null ) stuff = "not there";
divStuff.InnerHtml = Convert.ToString(stuff);

Первый шаг для консультанта для создания их кода синхронным, потому что их прием производительности не работал вообще. Если это фиксирует его, имейте консультанта, правильно реализуют использование Шаблона разработки Асинхронного программирования

Я соглашаюсь с ним частично - определенно лучше проверить y на нуль вместо того, чтобы ловить (дорогое) исключение. bool isSuccessful кажется действительно датированным мне, но безотносительно.

ре: асинхронное sessionid шутовство - может или не может быть верным, но оно кажется, что консультант уносит дым для покрытия.

На асинхронной части единственный путь, который мог быть верным, состоит в том, если присвоение, продолжающееся, существует на самом деле метод set индексатора на Сессии, которая скрывает асинхронный вызов без успеха/отказа указания обратного вызова. Это, казалось бы, было бы УЖАСНЫМ проектным решением, и оно похоже на базовый класс в Вашей платформе, таким образом, я нахожу его очень вряд ли.

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

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

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

int MyFunction(int x, int y)
{
    if (y == 0)
    {
        // log it
        throw new DivideByZeroException("Divide by zero attempted!");
    }

    return x / y; 
}

Этот парень не знает то, что он делает. Очевидный преступник прямо здесь:

Session["UserID"] = SomeProprietarySessionManagementLookup();

Эмпирическое правило: Если необходимо спросить, знает ли консультант то, что он делает, он, вероятно, не делает ;)

И я склонен соглашаться здесь. Очевидно, Вы не обеспечили очень, но они не кажутся ужасно компетентными.

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

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