Насколько эластичный мое веб-приложение должно быть? [закрытый]

Это вероятно, более академический ответ, учитывая, что вы унаследовали этот код. Если вы используете или, вернее, кто-то использовал шаблон Microsoft.Practices.EnterpriseLibrary.ExceptionHandling ExceptionPolicy, тогда действительно легко переключиться с отображения страницы с ошибкой (путем выдачи исключения) на прием исключений и отображение пустых сеток, списков и т. Д.

Возможно, вы уже знаете об этом небольшом шаблоне, но вот он:

        try
        {
            //get data
        }
        catch (Exception ex)
        {
            if (ExceptionPolicy.HandleException(ex, "Data Access Exception"))
                throw ex;
        }

Ваш начальник должен был обсудить с клиентом, прежде чем создавать приложение. Такие термины, как «некритичный», следует определять как число (процент времени безотказной работы). Некоторым приложениям требуется, чтобы разные части приложения имели разное время безотказной работы (что предлагает ваш начальник), а приложения работают / не работают в целом (как это работает сейчас). «Устойчивое» приложение, вероятно, будет написано другим способом (распределенное чтение / асинхронная запись и т. Д.), Чем «нормальное» приложение, поэтому (вероятно) будет сложно преобразовать «нормальное» приложение.

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

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

Возможно, вы просто показываете общую страницу с ошибкой, когда подойдет пустой набор данных и «удобное для пользователя» сообщение об ошибке.

Так, например, если вы показываете список пользователей / сообщений / даты, но служба, в которой вы их собираете, не работает, вы, вероятно, можете показать пустой набор.

Вместо того, чтобы показывать:

500 Server Error




.

Вы можете показать что-то вроде:

 User   |    Message     | Date 
 ------------------------------
    No data available* 




* Xyz service is be down. 

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

Это сильно варьируется в зависимости от того, что вы используете, но в целом это может быть очень просто:

 List<Data> data = EmptyList<Data>();

 try 
 {
     data = service.GetData();
 } catch( ServiceUnavailableException error ) 
 {
     errorPage.SetMessage( service.GetName() + " service is down ");
     // log the error message
    logger.doLog( error );
 } 

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

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

Для внешних служб, таких как обращение к SMTP-серверу или базе данных, которые не используются большей частью остальной части приложения у нас обычно есть код, который просто отображает обратную связь на странице, если служба / база данных не работает / недоступна.

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

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

При этом лучшие практики моей компании включают в себя кодирование, чтобы что-то вроде ошибки БД плавно переходило на пользовательский конец к сообщению «не удается подключиться» в выходных данных, а не к полноценной ошибке типа 404. Я обнаружил, что на самом деле это не добавляет больше, чем несколько минут к процессу кодирования, и ценность того, чтобы не раздражать пользователя, стоит своих «затрат»

Это зависит ... многие веб-страницы отображают и отображают отдельные «виджеты». Каждый виджет может использовать разные источники данных ... некоторые могут быть даже полностью статичными. Я согласен с вашим боссом с точки зрения того, что если по какой-либо причине не удается загрузить один виджет, мы все равно должны попытаться загрузить остальную часть страницы. Один сбойный виджет не должен мешать пользователю взаимодействовать с остальной частью сайта.

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

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

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