views:

45

answers:

1

Ok Im building AN API but also wanting to have that API used by my own Application. I am pondering WCF, LinQ and JSON for my Webservices and Data and Silverlight for my application.

I have a few questions.

1) would you recommend XML over JSON or Json over XML? a) is Json going to transfer and deserialize faster natively or is XML going to transfer and deserialize faster?

2) would Using LINQ hinder anyone connecting to my Service form PHP?

3) Would you recommend something different?

+1  A: 

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.

andy
ahha Awesome answer. I think i understand Your saying From a Silverlight Standpoint Ill Be using Linq to SQL and sending objects across, that there is no reason to serialize to json or XML, I don't want to build the business logic 3 times how would you take somethign you already did in Linq2SQL and create an endpoint for JSONDo you know of a simple exmaple?
Rico
WCF RIA Services (which I would likely recommend for this setup) would also allow Binary Encoding which should be faster than the other options when dealing with Silverlight.
Rangoric
yep, that's right, I forgot about ria services. but that woldn't work with his pup clients would it?
andy
Andy,Hey sorry any good examples of DTO's Is a DTO just a class I create? with properties and such?
Rico
absolutely, a DTO is just a class which persists data. ideally it wouldn't have any public methods, although mine usually contain methods for serializing or desrealizing the object... usually for logging purposes. Your DTOs shouldn't be dependent on any logic, and they should be in a separate assembly. they're really just lightweight objects that only contain information that they need. like, your db entities might contain timestamps, or foreign keys, but your DTOs probably don't need to know about that. lastly, as you're using wcf, they'll probably need wcf attribute decorations...
andy