slow down there partner! ;-)
I think you've kinda confused yourself with a lot of acronyms.... let's break things up and get a better understanding of each technology.
I think this is what you want:
- An API in the form of a webservice(s), and a client App in silverlight.
- You also want client other than silverlight to consume your webservice API
Is that right? let me know and we can break things down further.
Update
Ok, when you say LINQ, you must mean Linq2Sql? in which case that's your data layer... so it shouldn't matter what technology you use for your data access, because all your webservice should be serving up are DTOs.
As for serialization... as you want to use WCF, and as long as you're using DTOs, then you should build your API independently of your serialization. That can be handled by the type of "bindings" you configure in WCF. So, for now, it shouldn't matter.
On that note, because you can have multiple "WCF endpoints" for each service, you could provide a JSON one, AND an XML (restful) one, and even a SOAP one.. without writing too much extra code.
I personally prefer XML, as it's super easy to parse in .net using Linq to Xml, but JSON is less verbose and arguably has a smaller footprint.
In Response to your Comment
hey rico, thanks. Not quite.
So, your silverlight app would just be a client that consumes your webservice.
Your webservice would provide your client with any data it needs in the form of DTOs. You can of course have some kind of system in your client which caches DTOs so you don't have to call the webservice all the time... or you could come up with some kind of syncing solution.... but wither way....
...your webservice is the only one which talks to the DB, which in turn lives on your server. So, it's your webservice which talks to your DAL (Data Access Layer), and that in turn could implement Linq2Sql, or any other data access technology.