int dummyInt;
if(Int32.TryParse(months,out dummyInt))
return "Yes, it is integer";
else
return "No, it is not an integer";
Today we'll touch the three most lauded concepts introduced by the XAML (eXtensible Application Markup Language). XAML to me seems like XML + .NET. By that I mean XAML provides you the best of both worlds by leveraging descriptive nature of XML and object-oriented nature of .NET. It allows you to instantiate a .NET object like WatermarkedTextbox and describe it properties using pure XML driven syntax, and all that in the Markup. So lets go ahead and explore these three majestic Xaml concepts :
Property Element Syntax
Basically in XAML markup we have three types of element syntaxes
To understand them one by one, lets take an example of the a simple WPF control, the TextBlock
<TextBlock Text="Title:" Style="{StaticResource TextBlockStyle}"
Grid.Row="0" Grid.Column="0" HorizontalAlignment="Right"></TextBlock>
Object element syntax refers to the way we have instantiated a .NET object ie TextBlock. Attribute element syntax means to how have used XML attributes (like HorizontalAlignment above) to define that object's properties and given it a value (ie Right). Now assume for a while that we have a TextBlock that displays a custom drawing instead of just plain text. Such TextBlock definition will look like this
<TextBlock Style="{StaticResource TextBlockStyle}" Grid.Row="0" Grid.Column="0" HorizontalAlignment="Right">
<TextBlock.Text>
<Canvas>..Drawing here...</Canvas>
</TextBlock.Text>
</TextBlock>
Property Element syntax pertains the way have defined the TextBlock's property comprehensively (a detailed drawing object) instead of just a word "Title:". So this ability of XAML to support myriad of property definitions is branded by the magic word "Property Element Syntax". Just for the sake of readability we'll cover the next 2 concepts in the subsequent post which can be found here
| SOAP | REST |
| SOAP clients call every SOAP operation on the server using only Http GET | REST clients leverage true functionality of HTTP methods like GET,POST,PUT and DELETE and use them to call the REST service |
| SOAP is operation centric | REST is resource centric |
| SOAP mandates the use of WSDL and proxies on all the clients which need to call SOAP web service | REST call be called from any client on any platform with using any proxy or WSDL |
| If SOAP WS Interface changes, you need to update proxies on the all clients which are hooked to that SOAP WS | REST services doesn't have this limitation |
| SOAP puts overhead of and on the XML data | REST doesn't put any such overhead |
| Stateful SOAP services are not scalable | REST services are stateless by design so they are scalable |
| Stateful SOAP services create much headache in Load-balanced environment | Because REST is fundamentally stateless, this headache doesn't arises |
| SOAP objects are not cache-able | REST Uris are cache-able |
| SOAP puts additional overhead of SoapBody and SoapEnvelope which is considerable for low bandwidth clients like PDAs, Smartphones, etc | REST doesn't have this limitation |
| SOAP is slower because it consumes time parsing XML and serializing objects | REST is faster because its simpler and doesn't have such schema dependencies |
| SOAP has a bigger learning curve as developers need to fully understand WSDL, UDDI, WS-* | REST has very shorter learning curve as it extends directly from HTML |
The next figure shows how Proxy and Configuration files are automatically created 
You can understand the differeces between Add Web Reference and Add Service Reference in my next post here