A debate has been going on at work about using Convert.ChangeType.A couple of fundamental assumptions to this discussion are delineated below:1. The discussion is within the context of web applications.2. The types to which I want to perform casts are primitive types.Now, to the argument itself: would using primitive type casting such as  if (int.TryParse(anyString, out result))   {     myObjectIntProperty = result;  }  else  {     // myObjectIntProperty = 0, default(int)  }be preferred over a generic approach, such as having a function like private static  T x<T>(object o){    try    {       return (T) Convert.ChangeType(o, typeof(T));     }    catch(Exception)    {       return default(T);    }}?Side A of the argument (not mine) claims that for 1.000.000 requests using int.TryParse and the likes is faster (I checked it and the difference sticks around 100 miliseconds). The claim here is business-wise.My side - from a developer perspective - says that giving up the generic approach is annoying, counter-productive, contradicts many principles of software engineering (reusability, functionality-unique-definition). This leaves me having to code the same checkings over and over again. What is wrong with building a infrastructure library, to provide all common required tasks throghout the project ?! Besides, I think the performance issue here is irrelevant to the context where the application exists.Please, leave your comment or opinion about this. It is extremely frustrating when you have 2 mutually exclusive ideas, you think one is the correct one and you end up having to accept the adoption of the other.
Argument over performance using Convert.ChangeType in Web Applications
c#;performance;parsing