Programming Microsoft ASP.NET 4 - Dino Esposito [464]
JSON at a Glance
JSON is a text-based format specifically designed to move the state of an object across tiers. It’s natively supported by JavaScript in the sense that a JSON-compatible string can be evaluated to a JavaScript object through the JavaScript eval function. However, if the JSON string represents the state of a custom object, it’s your responsibility to ensure that the definition of the corresponding class is available on the client.
The JSON format describes the state of the object, an example of which is shown here:
{"ID"="ALFKI", "Company":"Alfred Futterkiste"}
The string indicates an object with two properties—ID and Company—and their respective, text-serialized values. If a property is assigned a nonprimitive value—say, a custom object—the value is recursively serialized to JSON, as in the code snippet shown here:
{"ID"="ALFKI",
"Company":"Alfred Futterkiste",
"Address":{"Street="543 Oberstr", "City"="Berlin", "Country":"Germany"} }
Services in the HTTP façade preferably receive and return HTTP packets with JSON content.
On the client, creating a JSON representation of data is your responsibility. You can either manually build the string or use some facilities to serialize a JavaScript object to JSON. Some browsers support native JSON parsing through a JSON object exposed out of the window object. Specifically, these browsers are Internet Explorer 8, Firefox 3.5, Safari 4, Chrome, Opera 10, and their newer versions. Alternatively, you can download the file json2.js, which provides analogous capabilities, from http://www.json.org.
On the server, you typically rely on the serialization capabilities of some classes in the .NET Framework to get a JSON string. You can use the JavaScriptSerializer class or the newer DataContractJsonSerializer class. Although they do it through different APIs, both classes take a .NET object and convert it to a JSON string. This step, however, is transparently performed by the WCF infrastructure after you have defined the data contracts for the service interface.
Data Contracts
Any nonprimitive data to be sent or received via WCF methods must be marked with the DataContract attribute. Imagine you have the following service:
[ServiceContract(Namespace = "Services.Wcf")]
[AspNetCompatibilityRequirements(
RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class CustomerService
{
[OperationContract]
public CustomerDTO LookupCustomer(String id)
{
var context = new NorthwindDataContext();
var data = (from c in context.Customers
where c.CustomerID == id
select c).SingleOrDefault();
if (data != null)
{
var dto = new CustomerDTO((Customer)data);
return dto;
}
return new MissingCustomerDTO();
}
}
The method LookupCustomer is expected to return a custom object. This object must be decorated with ad hoc DataContract attribute:
namespace Services.Wcf
{
[DataContract]
public class CustomerDTO
{
private Customer _customer;
public CustomerDTO(Customer customer)
{
_customer = customer;
}
[DataMember]
public string CustomerID
{
get { return _customer.CustomerID; }
set { _customer.CustomerID = value; }
}
...
}
}
In this particular case, the class being used over WCF is a data-transfer object (DTO)—that is, a helper class that moves the content of domain model objects across tiers.
Why JSON Is Preferable to XML
For years, XML has been touted as the lingua franca of the Web. Now that Ajax has become a key milestone for the entire Web, XML has been pushed to the side in favor of JSON as far as data representation over the Web is concerned.
Why is JSON preferable to XML in Ajax scenarios?
The main reason for dropping XML and SOAP in favor of JSON is that JSON is much easier to handle from within a JavaScript-powered client than any XML-based format. JSON is slightly simpler and more appropriate for the JavaScript language to process than XML. Although JSON might not be easier for humans