Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>What you're describing sounds like an example of the aphorism, "You can write FORTRAN in any language."</p> <p>A massive class full of static methods is often (not always) a sign that somebody just didn't "get" OOP, was stuck in a procedural-programming mindset and was trying to twist the language to do what he wanted.</p> <p>As a rule of thumb: If any method, static or instance, takes more than about 5 parameters, it's often a sign that the method is trying to do too many things at once, and is a good candidate for refactoring into one or more classes.</p> <p>Also, if the static methods are not really related, then they should <em>at least</em> be split up into classes that implement <em>related</em> functionality.</p> <p>I'm actually wondering why you'd have a "send e-mail" method at all, given that the <code>System.Net.Mail</code> namespace handles just about every case, and is configurable via the app.config/web.config file, so you don't need to pass it a server name or port. Is this perchance a "notification" method - something that individual pages are supposed to call out to in order to send one of several "standard" messages based on templates with various values filled in, and certain headers/footers automatically added? If so, there are a number of designs for this type of interaction that are much easier to work with than what you seem to have inherited. (i.e. <a href="http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.maildefinition.aspx" rel="nofollow noreferrer">MailDefinition</a>)</p> <p><strong>Update:</strong> Now having seen your comment that this is being used for exception handling, I think that the most appropriate solution is an actual <em>exception handler</em>. There are a ton of resources on this. For ASP.NET WebForms, I actually took the one Jeff Atwood wrote years ago, ported it to C# and made a few changes (like ignoring 404 errors). There are a number of good links in <a href="https://stackoverflow.com/questions/55961/exception-handling-in-net-web-apps">this previous question</a>.</p> <p>My preference these days is just to treat exception handling (and subsequent e-mailing of exception reports) as a subset of logging. <a href="http://logging.apache.org/log4net/index.html" rel="nofollow noreferrer">log4net</a> has an <a href="http://logging.apache.org/log4net/release/sdk/log4net.Appender.SmtpAppender.html" rel="nofollow noreferrer">SmtpAppender</a> that's quite capable, and you can configure it to only be used for "fatal" errors (i.e. unhandled exceptions - in your handler, you just make a <code>LogFatal</code> call).</p> <p>The important thing, which you'll no doubt pick up from the SO link above and any referenced links, is that there are actually two anti-patterns here - the "miscellaneous" static class, and <em>catching exceptions that you don't know how to handle</em>. This is a poor practice in .NET - in most cases you should only catch application-specific exceptions that you can recover from, and let all other exceptions bubble up, installing a global exception handler if necessary.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload