Convert string to a known type (using its default converter)

I was in a need to get a type, instantiate it and then fill its properties (I'm currently doing an engine that will give me an instant CRUD UI).

So what I basically needed was to be able to fill a new object instance out of a Hashtable (the key is the name of the property and the value is its string representation).

I wanted to be able to convert that string value into the type it needs to be.
Here is some code to help you get it:

foreach(string strPropertyName in htValues.Keys)
{
PropertyInfo pi = entity.GetType()
.GetProperties()
.ToList()
.FirstOrDefault(property => property.Name == strPropertyName);
}
(this is kind of pretotype so don't blame me if you don't like the code :).

In the above code I am iterating in the keys of the hashtable, so if I have an user object it will strPropertyName will hold "FirstName", then "LastName".
So far so good, I am able to fill the object and send it to the EntityFramework for DB Persistance.

The problem was when the strPropertyName was holding "BirthDate" as it is a DateTime and the EntityFramework or the Reflection (not quite sure which one) was crying it can't Convert the string to the respective type for me.

Here is how I solved the problem:
// Create a new Instance of the given type.
object entity = Activator.CreateInstance(this.EntityType);
// Iterate through all the properties.
foreach(string strPropertyName in htValues.Keys)
{
// Get the property with that name:
PropertyInfo pi = entity.GetType()
.GetProperties()
.ToList()
.FirstOrDefault(property => property.Name == strPropertyName);
// Get the default type converter for the given property type:
TypeConverter converter = TypeDescriptor.GetConverter(pi.PropertyType);
// Set the value by converting non-values to the given type
// and setting null where it is a null value.
pi.SetValue(entity, htValues[pi.Name] == null ? null : converter.ConvertFromString(htValues[pi.Name].ToString()), new object[] { });
}

Basically the thing you (and I!) need to remember is that the TypeDescriptor class has a GetConverter() method that takes a type and returns a TypeConvertor for that type.

Now in order to be able to convert from string to that type you just need to call .ConvertFromString(string value) of the TypeConverter returned by the TypeDescriptor.

Hope this helps someone out there. To me it seems it can give you a great deal of abstraction and I (for some reason) believe this is heavilly used in nowadays OR/M's.

When to decouple?

It is quite modern nowadays to decouple things. One project in USA to deal one business requirement, another in Pakistan to deal with some other business requirement and one more in Romania and one more in Bulgaria... Is it so good indeed to decouple single project into Web services and make them talk each other? Well I think as most things in this life decoupling has its advantages and disadvantages. I nearly lost my mental health becouse of an xslt to transform an xml document to another xml document so it can be sent from a system we are developing to a system, which provides document printing. Does it worth to write 14, 000 lines of xslt code only to print a document? Well, depends on the viewpoint. First of all decoupling minimizes

the development efforts in the corporation, by splitting it into development efforts in two or more corporations. That's good #1. Second - it can save years of gathering data (a good example are the credit providers in the USA, they have information you can hardly obtain other way but using their (paid) services). That's good #2.
The support is done by the other party, you don't need to care about it. That's good #3.
The other good thing is that there's always someone else to blame for something not working ;). That's joke ofcourse. The truth is that if your code doesn't work - you'll lose your clients. That's the simple truth about any business.

Now let's turn our attention on the disadvantages the SOA and decoupling may bring to you. The first and one of the biggest disadvantages is that YOU ARE DEPENDING ON SOMEONE ELSE. Any technical problem on their side will affect your side and what's worse - it will also affect your customers. And what is even worse- it will (in most cases) harm your reputation, not the reputation of the party that made the mistake (so be careful about what are you writing in the error messages the customer will see on other party fail;). Yeah, I mean it. You shouldn't accept the other party guilt as yours, if they could delivered it to you, you would have delivered it to the client, right? So instead of writing :
"Error, we have a problem"
write :
"Error, our partner have a problem."
Other big disadvantage is that while developing your side code you are facing a black box. You don't know what's happening in this black box and why it is responding in the way it does. You can only trust the documentation you may have. But is everything in it? No, I don't think so. Especially for complex services some small things are always missing and you need to either figure them out (which costs a lot of money for pills) or contact the other party and wait so they can clear the problem and document it.
I remember once I faced great problems with a web service which simply refuses to return any response. Only some simple empty xml document. Finally we figured out with my colleagues it needed two spaces in the begining of the document. I remember I wanted to swim from Bulgaria to USA to ask the guys who developed this thing to show me how would the request the document. The development dificulties, however are not a great obstacle, becouse once passed, they won't worry you anymore. But there is one more disadvantage which will remain - the transportation of the data. In order to get response from a third party service you need to send it request (this request is transported over the Internet), the service needs time to process it and then it returns you the request (which is also transported over the Internet). Then you may do something with this request and send response to the client (which is also done over the Internet). So instead one response / request pairs, you will have two. That's 100% bandwidth growth. It isn't something you can live with.

So the question remains. When should we use decoupling and SOA (I mean services, provided by third parties)?

I think it is a good choice to use third party services when you need some sort of information which is hard to obtain or may require too much time and which someone already have (credit reports in USA are good example, I think). You also may consider using SOA for services which will require a lot of time for development and which are already developed by third parties. For simple services - I think it is better to develope them on your own, so you don't waste too much bandwidth and depend on other parties.