Singleton Pattern implementation using Private Constructor in C#

In this article, I have tried to show the implementation of singleton pattern in C# using Private constructor. the source of this article is dofactory

using System; namespace ConsoleApplication1 {   /// <summary>   /// MainApp startup class for Structural   /// Singleton Design Pattern.   /// </summary>   class Program   {     /// <summary>     /// Entry point into console application.     /// </summary>    public  static void Main()     {       // Constructor is private-- cannot use new       Singleton s1 = Singleton.Instance(); // trick to creating object        Singleton s2 = Singleton.Instance();       // Test for same instance       if (s1 == s2)       {         Console.WriteLine("Objects are the same instance");       }       // Wait for user       Console.ReadKey();     }   }   /// <summary>   /// The 'Singleton' class   /// </summary>   class Singleton   {     private static Singleton _instance;     // Constructor is 'private'     private Singleton()     {     }     public static Singleton Instance()     {       // Uses lazy initialization.       // Note: this is not thread safe.       if (_instance == null)       {         _instance = new Singleton(); // creating the instance and guaranteeing for single instance        }       return _instance;     }   } }

Output Objects are the same instance

Adding a Contact Us Form and sending email with ASP.NET 4.0 and C#

Feed back form in asp.net 4.0 using gmail account for sending mail.


This tutorial will demonstrate how to add a simple Contact Us form for users to leave feedback via email in ASP.NET and C#. 

Setting Up the Form 
At this point in the tutorial I have created a new ASP.NET Empty Web Site in Microsoft Visual Studio and have added in a blank Web Form named Default.aspx. What we need to do now is setup a simple form to collect the data from the user. This will include a Name, Subject, and Message. Also, we will need a submit button that the user will click to send the email, and a label to show a result if the email was sent or not.

To do this, open up Default.aspx to source mode and add the following code in the div tag:

<h2>Contact Us</h2> <br /> <table>     <!-- Name -->     <tr>         <td align="center">             Name:</td>         <td>             <asp:TextBox ID="txtName"                              runat="server"                             Columns="50"></asp:TextBox>         </td>     </tr>     <!-- Subject -->     <tr>         <td align="center">             Subject:         </td>         <td>             <asp:DropDownList ID="ddlSubject" runat="server">                 <asp:ListItem>Ask a question</asp:ListItem>                 <asp:ListItem>Report a bug</asp:ListItem>                 <asp:ListItem>Customer support ticket</asp:ListItem>                 <asp:ListItem>Other</asp:ListItem>             </asp:DropDownList>         </td>     </tr>     <!-- Message -->     <tr>         <td align="center">             Message:         </td>         <td>             <asp:TextBox ID="txtMessage"                              runat="server"                             Columns="40"                             Rows="6"                              TextMode="MultiLine"></asp:TextBox>         </td>     </tr>     <!-- Submit -->     <tr align="center">         <td colspan="2">             <asp:Button ID="btnSubmit" runat="server" Text="Submit"                  onclick="btnSubmit_Click" />         </td>     </tr>                  <!-- Results -->     <tr align="center">         <td colspan="2">             <asp:Label ID="lblResult" runat="server"></asp:Label>         </td>     </tr> </table>

If you then open the Default.aspx page up to design mode you should see a table that looks similar to this: 

Adding the Code 
The next thing we need to do is add the code to send the data from the form to our email address in the event that the submit button is clicked. To do this, double click the submit button to generate the Click event method for that button. Now in the Default.aspx.cs file, we will want to add in a few using statements that will allow us to send this email. Under the other using statements, add the following:

using System.Net.Mail; using System.Net;

Next, we need to add some code to the Button's Click event method. The following code is a template for sending an email using a Gmail account, however you will need to customize this based on the RecipientAddress, which will be the email you are sending the message to, the SenderAddress, which will be the email account you will be sending the message from and also the SMTP server and port that are appropriate for your email provider.

try {     //Create the msg object to be sent     MailMessage msg = new MailMessage();     //Add your email address to the recipients     msg.To.Add("RecipientAddress@gmail.com");     //Configure the address we are sending the mail from     MailAddress address = new MailAddress("SenderAddress@gmail.com");     msg.From = address;     //Append their name in the beginning of the subject     msg.Subject = txtName.Text + " :  " + ddlSubject.Text;     msg.Body = txtMessage.Text;     //Configure an SmtpClient to send the mail.     SmtpClient client = new SmtpClient("smtp.gmail.com", 587);     client.EnableSsl = true; //only enable this if your provider requires it     //Setup credentials to login to our sender email address ("UserName", "Password")     NetworkCredential credentials = new NetworkCredential("SenderAddress@gmail.com", "xxxx");     client.Credentials = credentials;     //Send the msg     client.Send(msg);     //Display some feedback to the user to let them know it was sent     lblResult.Text = "Your message was sent!";     //Clear the form     txtName.Text = "";     txtMessage.Text = ""; } catch {     //If the message failed at some point, let the user know     lblResult.Text = "Your message failed to send, please try again."; }

Pagination or paging in SQLserver 2005/2008

 Equivalent of LIMIT and OFFSET for SQL Server 2005/2008

Introduction

The paging and ranking functions introduced in 2005 are old news by now, but the typical ROW_NUMBER OVER() implementation only solves part of the problem.

Nearly every application that uses paging gives some indication of how many pages (or total records) are in the total result set. The challenge is to query the total number of rows, and return only the desired records with a minimum of overhead? The holy grail solution would allow you to return one page of the results and the total number of rows with no additional I/O overhead.

In this article, we're going to explore four approaches to this problem and discuss their relative strengths and weaknesses. For the purposes of comparison, we'll be using I/O as a relative benchmark.

The 'two-bites' approach

The most basic approach is the 'two-bites' approach. In this approach you, effectively, run your query twice; querying the total rows in one pass, and querying your result set in the second. The code is pretty straightforward:

DECLARE @startRow INT ; SET @startrow = 50
SELECT COUNT(*) AS TotRows
FROM [INFORMATION_SCHEMA].columns

;WITH cols
AS
(
    SELECT table_name, column_name,
        ROW_NUMBER() OVER(ORDER BY table_name, column_name) AS seq
    FROM [INFORMATION_SCHEMA].columns
)
SELECT table_name, column_name
FROM cols
WHERE seq BETWEEN @startRow AND @startRow + 49
ORDERBY seq

It gives the desired results, but this approach doubles the cost of the query because you query your underlying tables twice:

(1 row(s) affected)
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'syscolpars'. Scan count 1, logical reads 46, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysschobjs'. Scan count 1, logical reads 34, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(50 row(s) affected)
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'syscolpars'. Scan count 1, logical reads 46, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysschobjs'. Scan count 1, logical reads 34, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

The temp table approach

The 'two-bites' approach is especially undesirable if your paged query is very expensive and complex. A common workaround is to write the superset into a temporary table, then query out the subset. This is also the most common way to implement paging pre-2005 (in this case, ROW_NUMBER is superfluous).

DECLARE @startRow INT ; SET @startrow = 50
CREATE TABLE #pgeResults(
    id INT IDENTITY(1,1) PRIMARY KEY CLUSTERED,
    table_name VARCHAR(255),
    column_name VARCHAR(255)
)
INSERT INTO #pgeResults(Table_name, column_name)
SELECT table_name, column_name
FROM [INFORMATION_SCHEMA].columns
ORDERBY [table_name], [column_name]

SELECT @@ROWCOUNT AS TotRows
SELECT Table_Name, Column_Name
FROM #pgeResults
WHERE id between @startrow and @startrow + 49
ORDER BY id

DROPTABLE #pgeResults

Looking at the query plan, you can see that your underlying tables are queried only once but the I/O stats show us that you take an even bigger hit populating the temporary table.

Table '#pgeResults_________________________________________________________________________________________________________000000001A9F'. Scan count 0, logical reads 5599, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'syscolpars'. Scan count 1, logical reads 46, physical reads 0, read-ahead reads 14, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysschobjs'. Scan count 1, logical reads 34, physical reads 0, read-ahead reads 39, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(2762 row(s) affected)

(1 row(s) affected)

(50 row(s) affected)
Table '#pgeResults_________________________________________________________________________________________________________000000001A9F'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

In this case, it would be better to query the tables twice. Maybe some new 2005 functionality can yield a better solution.

The COUNT(*) OVER() Approach

OVER() can also be used with Aggregate Window Functions. For our purposes this means we can do a COUNT(*) without the need for a GROUP BY clause, returning the total count in our result set. The code definitely looks much cleaner and, if your application permits it, you can simply return one dataset (eliminating the overhead of writing to a temp table).

DECLARE @startRow INT ; SET @startrow = 50

;WITH cols
AS
(
    SELECT table_name, column_name, 
    ROW_NUMBER() OVER(ORDER BY table_name, column_name) AS seq, 
    COUNT(*) OVER() AS totrows
    FROM [INFORMATION_SCHEMA].columns
)
SELECT table_name, column_name, totrows
FROM cols
WHERE seq BETWEEN @startRow AND @startRow + 49
ORDER BY seq

Unfortunately this approach has it's own hidden overhead:

Table 'Worktable'. Scan count 3, logical reads 5724, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'syscolpars'. Scan count 1, logical reads 46, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysschobjs'. Scan count 1, logical reads 34, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Where did that come from? In this case, SQL Server implements the COUNT(*) OVER() by dumping all the data into a hidden spool table, which it then aggregates and joins back to your main output. It does this to avoid re scanning the underlying tables. Although this approach looks the cleanest, it introduces the most overhead. 

I've spent most of today cleaning up and old data-paging proc that is both very inefficient and frequently called enough for me to notice it. I've explored probably a dozen other approaches to solving this problem before I came up with the solution below. For the sake of brevity—and because they rest are pretty obscure and equally inefficient­—we'll now skip to the best solution.

The Holy Grail

In theory, ROW_NUMBER() gives you all the information you need because it assigns a sequential number to every single row in your result set. It all falls down, of course, when you only return a subset of your results that don't include the highest sequential number. The solution is to return a 2^nd column of sequential numbers, in the reverse order. The total number of the records will always be the sum of the two fields on any given row minus 1 (unless one of your sequences is zero-bound).

DECLARE @startRow INT ; SET @startrow = 50
;WITH cols
AS
(
    SELECT table_name, column_name, 
        ROW_NUMBER() OVER(ORDER BY table_name, column_name) AS seq, 
        ROW_NUMBER() OVER(ORDER BY table_name DESC, column_name desc) AS totrows
    FROM [INFORMATION_SCHEMA].columns
)
SELECT table_name, column_name, totrows + seq -1 as TotRows
FROM cols
WHERE seq BETWEEN @startRow AND @startRow + 49
ORDER BY seq

This approach gives us our page of data and the total number of rows with zero additional overhead! (well, maybe one or two ms of CPU time, but that's it) The I/O statistics are identical to querying just the subset of records.

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'syscolpars'. Scan count 1, logical reads 46, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysschobjs'. Scan count 1, logical reads 34, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Compare the stats above with the stats and query below (just returning one page of data).

;WITH cols
AS
(
    SELECT table_name, column_name, 
        ROW_NUMBER() OVER(ORDER BY table_name, column_name) AS seq
    FROM [INFORMATION_SCHEMA].columns
)
SELECT table_name, column_name
FROM cols
WHERE seq BETWEEN @startRow AND @startRow + 49
ORDER BY seq

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'syscolpars'. Scan count 1, logical reads 46, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysschobjs'. Scan count 1, logical reads 34, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Conclusion

I have found this approach to be best suited for smaller resultsets from complex queries where I/O is the primary bottleneck. Jeff Moden, Peso and others here have pointed out that with larger resultsets, the I/O cost you save is more than outweighed by the CPU cost. You definitly want to compare different approches to find the best solution for your problem.

My real goal here was to try and figure out a way to avoid unnecessary I/O overhead. I am sure that this solution is not the last word on the subject and I greatly look forward to hearing your thoughts, experiences and ideas on this topic. Thank you all for reading and for your feedback.

source: sqlservercentral