Optimizing a social network website
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.