То, что вы описываете, звучит как пример афоризма: «Вы можете писать на фортране на любом языке».
Массовый класс, полный статических методов, часто (не всегда) является признаком того, что кто-то просто не «получил» ООП, застрял в мышлении процедурного программирования и пытался изменить язык, чтобы сделать то, что он хотел.
Практическое правило. Если какой-либо метод, статический или экземпляр, принимает более 5 параметров, это часто является признаком того, что метод пытается сделать слишком много вещей одновременно, и является хорошим кандидатом для рефакторинга в один или больше классов.
Кроме того, если статические методы на самом деле не связаны, то они должны по крайней мере быть разделены на классы, которые реализуют связанную функциональность.
Мне действительно интересно, почему у вас вообще есть метод «отправить электронную почту», учитывая, что пространство имен System.Net.Mail обрабатывает практически каждый случай и настраивается через файл app.config / web.config , так что вам не нужно передавать ему имя сервера или порт. Является ли этот случай «уведомительным» методом - чем-то, что отдельные страницы должны вызывать для отправки одного из нескольких «стандартных» сообщений на основе шаблонов с заполненными различными значениями и автоматически добавляемых определенных верхних и нижних колонтитулов? Если это так, то существует целый ряд проектов для этого типа взаимодействия, с которыми гораздо проще работать, чем те, которые вы, кажется, унаследовали. (т. е. MailDefinition )
Обновление: Теперь, увидев ваш комментарий о том, что это используется для обработки исключений, я думаю, что наиболее подходящим решением является фактический обработчик исключений . На это есть масса ресурсов. Для ASP.NET WebForms я фактически взял тот, что написал Джефф Этвуд несколько лет назад, перенес его на C # и внес несколько изменений (например, игнорирование ошибок 404). Есть несколько хороших ссылок в этом предыдущем вопросе .
В настоящее время я предпочитаю рассматривать обработку исключений (и последующую отправку отчетов об исключениях по электронной почте) как подмножество ведения журнала. log4net имеет SmtpAppender , который вполне способен, и вы можете настроить его так, чтобы он использовался только для "фатальных" ошибок (то есть необработанных исключений - в вашем обработчике вы просто делаете LogFatal звоните).
Важная вещь, которую вы, без сомнения, заметите в приведенной выше ссылке SO и любых ссылочных ссылках, состоит в том, что на самом деле здесь есть два анти-паттерна - «разный» статический класс и , перехватывающий исключения, которые Вы не знаете, как обращаться с . Это плохая практика в .NET - в большинстве случаев вы должны отлавливать только исключения для конкретных приложений, из которых можно восстановить, и позволить всем остальным исключениям всплыть, при необходимости устанавливая глобальный обработчик исключений.