Optimizing a social network website I am developing my social network website, and I want to know if it's optimized or not.  I am good at ASP.NET 4 and WebForms, but not MVC or JavaScript.

This code is for "liking" a post.  I did not use any JavaScript to do that.  Is this "like" button optimized or not?  How many online users can my server handle (assume max online user is 500-700)?

protected void like_Click(object sender, EventArgs e)
{
    try
    {
        int ID = Convert.ToInt32(Session["ID"].ToString());
        LinkButton like = (LinkButton)sender;
        GridViewRow gvrow = (GridViewRow)like.NamingContainer;
        int ActivityTypeID = Convert.ToInt32(activity.DataKeys[gvrow.RowIndex].Values["ActivityTypeID"].ToString());
        int SourceID = Convert.ToInt32(activity.DataKeys[gvrow.RowIndex].Values["SourceID"].ToString());
        LinkButton unlike = gvrow.FindControl("unlike") as LinkButton;
        Label numberoflike = gvrow.FindControl("numberoflike") as Label;
        like.Visible = false;
        unlike.Visible = true;
        if (ActivityTypeID == 1 || ActivityTypeID == 4)
        {
              //check users liked it before or not ?
              // this code will run a stored procedure 
            if (BusinessLayer.StatusLike_Table.GetByIsliked(SourceID, ID, 1) == 0)
            {
              // make an object of like table
                BusinessLayer.StatusLike_Table nl = new BusinessLayer.StatusLike_Table();
                nl.Id = Convert.ToInt32(Session["ID"].ToString());
                nl.Statusid = SourceID;
                nl.Statuslikedate = System.DateTime.Now;
                nl.Save();
                  // saves like to database
                numberoflike.Text = BusinessLayer.StatusLike_Table.GetByNumberOfLike(SourceID).ToString();
             // update number of like by counting all likes for this post
            }

                     }
        else if (ActivityTypeID == 2 || ActivityTypeID == 5)
        {
            if (BusinessLayer.StatusLike_Table.GetByIsliked(SourceID, ID, 2) == 0)
            {
                BusinessLayer.PhotoStsLike_Table nl = new BusinessLayer.PhotoStsLike_Table();
                nl.Id = Convert.ToInt32(Session["ID"].ToString());
                nl.Photostsid = SourceID;
                nl.Photostslikedate = System.DateTime.Now;
                nl.Save();
                numberoflike.Text = BusinessLayer.PhotoStsLike_Table.GetByNumberOFlike(Convert.ToInt32(SourceID)).ToString();
            }
        }
    }
    catch (Exception ee)
    {
    }
}


For the commenting system and posting system and etc, the code is the same as above.  If all the code will be server-side and does not use any JavaScript, does it cause to have a slow website or not?

"Likes" are store on a database like this:

likeID int identity specification true ! identity increment true and 1
PostID int
ID int
Date Datetime  


I don't use any caching and I want to optimize user experience.
Not your primary concern, but a number of issues are jumping at me; I'll leave the performance aspects to other reviewers.


  Naming


like_Click should be renamed OnLikeButtonClicked or something similar, because it's a method, and method names in C# should be PascalCase (without underscores).

int ID should be renamed id, because it's a local variable, and local variables in C# should be camelCase.

LinkButton like should be renamed likeButton to not look like it's an action or something.

Notice how the syntax formatting gets confused with int ActivityTypeID and int SourceID? That's because PascalCase is for type and method names; these are local variables.

Label numberoflike is alllowercase and that's not helping readability. I'd call it something like likesCountLabel, indicating it's a control and that it's something about "likes count". Again, camelCase.




  Readability


Naming aside, a number of things could be done to improve readability here.


if (ActivityTypeID == 1 || ActivityTypeID == 4)



These values are known as magic numbers - nobody knows what they stand for, they just work. Consider defining an enum ActivityType instead, and refer to the values by their names.

Remove comments that state the obvious, that essentially rephrase what the code is already saying, and those that can eventually (read: will!) turn into blatant lies:


// this code will run a stored procedure 



Really? It's an implementation detail of that static/nested class (ew!), that this method doesn't need to care about. Whether it calls a stored procedure, concatenates T-SQL into a string, calls a web service and parses Json or XML to get your results, has no importance whatsoever. This comment is doomed, remove it.


// make an object of like table



Not needed. var myVariable = new MyType() already says everything we need to know.

That one is confusing:


    nl.Save();
      // saves like to database
    numberoflike.Text = BusinessLayer.StatusLike_Table.GetByNumberOfLike(SourceID).ToString();



Either put comments above the line they're commenting, or at the end of it... but not below! It makes it look like numberoflike.Text = ... is going to save something to the database. Yeah, right.

Avoid disemvoweling identifiers. nl means sweet nothing to anyone reading this code, and gvrow would probably be better off as simply row - the fact that it's a GridView isn't really important.




  Gotta catch'em alltm


This is called Pokemon exception handling:


catch (Exception ee)
{
}



Why? Because regardless of what's being thrown, it wil be caught. And then shoved under the carpet without leaving any trace. Not good: you should always catch the most specific exception types, those you can reasonably expect to be thrown, and properly handle them. Exceptions you didn't see coming, or that you can't properly handle, should bubble up the stack, get logged, and perhaps crash the application.

OTOH, you're getting a compiler warning, saying ee is declared but not used. You can eliminate that warning by going all-out on Pokemon handling:

catch (Exception){ }




The BusinessLayer static class smells, but changing it to be a constructor-injected instance would probably require massive structural changes.. I'd approach the refactoring with incremental steps towards dependency-injection, so as to facilitate unit-testing.