When making cross-domain requests from Silverlight applications you need a clientaccesspolicy.xml file to allow the communication between the service and the Silverlight application. And while it seems pretty straight-forward at first, things become quite inconvenient when you start working with Host Named Site Collections.
SharePoint 2010 ships with native support for Silverlight what makes creating Rich Internet Applications (RIA) easier and faster. And although Silverlight has been around for a couple of years now, there is more to developing Silverlight RIAs on SharePoint 2010. While you could use the classic – web-services-based approach, SharePoint 2010 ships with the Silverlight Object Model which makes it easy to work with data from SharePoint in Silverlight applications.
By default, when you create a User Control in Silverlight or Windows Presentation Foundation (WPF) all child controls are publicly available. This is not only bad for reusability of the control but also from the design point of view as you should always try to encapsulate the internals of your control and only make available to the outside world functionality that makes sense to them. Additionally encapsulating properties allows you to validate the input what makes your control less error prone.
SharePoint 2010 ships with Silverlight Object Model that simplifies working with SharePoint data within Silverlight components. Thanks to the new object model you no longer have to create and deploy custom services to retrieve data from SharePoint. Out of the box the Silverlight Object Model encapsulates calling standard SharePoint WCF Services which makes it extremely easy for you as a developer to create Silverlight components that communicate with SharePoint. Although working with the Silverlight Object Model is pretty easy, there is one thing that you have to keep in mind while developing for anonymous users.