It really bothers me to depend on WCF to provide DB support to Silverlight.
My guess is that Silverlight is client-side in the end, and Microsoft wants to give some kind of main access/entry-point for data which is the server-side code.
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
It really bothers me to depend on WCF to provide DB support to Silverlight.
My guess is that Silverlight is client-side in the end, and Microsoft wants to give some kind of main access/entry-point for data which is the server-side code.
Silverlight follows the web paradigm, and seems to try to bridge the gap between ASP.NET and your traditional desktop technologies.
Recently, Microsoft has made strides to provide more control to Silverlight applications running out of browser (PInvoke support for unmanaged code, Office integration, access to COM, support for peripherals, …). With all this it would seem like there is little stopping them from including database support. It could make sense in an out of browser scenario, and wouldn’t be any more of a security risk as running any other application you just downloaded.
However being built on the web paradigm, your data usually comes from the net. So this might be the reason for their reluctance to include it…
I guess, in the end, it is debatable.