JavaScriptSerializer

The JavaScriptSerializer lives in the System.Web.Script.Serialization namespace and the usage is fairly straight forward for serialization:

JavaScriptSerializer serializer = new JavaScriptSerializer();
String json = serializer.Serialize(data);

For deserialization however, there is a minor annoyance in that the deserializer accepts a generic type along with the content:

serializer.Deserialize<T>(String s)

which can be a problem if the type T is not known at compile time and needs to be dynamic. The work around is a bit ugly as I learnt because it uses reflection to create a generic method but it works:

var result = typeof(JavaScriptSerializer).GetMethod("Deserialize")
             .MakeGenericMethod(JsonDataType)
             .Invoke(serializer, new object[] { inputContent });

The JavaScriptSerializer is excellent for general purpose serialization and deserialization, however, one downside is that it cannot handle circular references.

A useful feature of the JavaScriptSerializer is that you can also implement a custom JavaScriptConverter and pass that in to JavaScriptSerializer for fine-grained control over the serialization/deserialization. However, for it to be really useful you need to know the types at compile time and have references to those types. This really limits the usefulness of this feature because by referencing those classes your code becomes tightly coupled so you cannot easily use it in something like an MVC filter.

The JavaScriptSerializer includes all public fields and properties for serialization by default which makes it useful when working with auto-generated classes or if you don’t have access to the source. This is different from how DataContractJsonSerializer works.

DataContractJsonSerializer

The DataContractJsonSerializer lives in the System.Runtime.Serialization.Json namespace. Unlike the JavaScriptSerializer, the DataContractJsonSerializer is a contract-based serializer so classes or members need to have the [DataContract], [DataMember] or the [Serializable] attribute.

[Serializable]
class Person {
    public String Name;
    public Int32 Age;
}

...

String json;
using (var stream = new MemoryStream()) {
    DataContractJsonSerializer serializer =
       new DataContractJsonSerializer(data.GetType());
    serializer.WriteObject(stream, data);
    json = Encoding.UTF8.GetString(stream.ToArray());
}

And for deserialization:

using(var stream = new MemoryStream(Encoding.Unicode.GetBytes(json)) {
    Object data = serializer.ReadObject(stream);
}

Since DataContractJsonSerializer is contract based and relies on attributes, it is not particularly suitable for auto-generated classes (unless they have these attributes) or when source is not accessible because the relevant attributes cannot be added at runtime as far as I know. However, for other situations attributes are an easy way to control the serialization aspects.

The most compelling feature of the DataContractJsonSerializer is that it can handle complex object graphs with circular references. This makes it particularly useful with the Entity Framework 4.0 which now support T4 templates allowing required [Serializable] or [DataMember] attributes to be added to auto-generated classes.

Json in MVC

The System.Web.Mvc namespace contains the Json function intended for use within ASP.NET MVC. There is no real reason to use it outside of ASP.NET MVC when JavaScriptSerializer and DataContractJsonSerializer are available. This function makes it extremely easy to serialize objects to a JSON string. It is not intended for deserialization, however, serialization is just one call:

String content = Json(data);

POCO Support

If you are not up to date on POCO, quickly read up on POCO and Persistence Ignorance first. Entity Framework 4.0 has full support for POCO or Plain Old CLR Objects.

If you have a class called Person with name, address and phone number then that’s how it will stay. It will not have EntityKey or some other such properties. It does not need to implement any interface specific to Entity Framework nor does it need to add any special attributes on properties and methods.

You can pass this plain object around much more cleanly and your domain logic is not polluted with any persistence code. This is also useful for Test Driven Development (TDD)  or migrating out of EF to another framework down the line.

Entity Model Designer Improvements

Previously you had to design the database schema in SQL Server and then import that into the Entity Designer. With 4.0 you can build the model first in the Entity Designer and generate your database and classes from there.  Alternately a lot of DDD (Domain Driven Design) folks prefer to hand code their model classes. Since those classes end up being POCO and EF has full support for POCO, it works out quite well for everyone.

T4 templates

Currently the Entity Designer generates classes from models by using EntityClassGenerator which provides little to no control over the generated classes. In 4.0 you will have T4 templates which provide for greater control over the generated classes with richer functionality like adding attributes to properties or having the generated classes implement a custom interface.

T4 templates are used not only to generate classes but also to generate tables if you choose to start off by building the models first. For example, by default the mapping is table-per-type which can be overridden through T4 templates to produce a table-per-hierarchy schema. You can also add prefixes to the generated table names and so on.

Self Tracking Entities and N-Tier applications

Self tracking entities are a very cool feature of the Entity Framework that allow for N-tier applications. Currently when you have entities on which you wish to track changes, the object context does that for you. However, the object context only exists in the current tier and if you decide to pass that object around to other tiers where the context is not present, you cannot track the entities any more. For example, if you pass the Person object to the UI layer which presents it to the user for modification, those modifications are not being tracked because the object context is not available in the UI tier. N-tier support can now handle this scenario quite elegantly.

One way to do this is to generate self-tracking entities as these entities have logic to track changes within. If the UI modifies the Person object’s address, the Person object will now contain information on how it’s been modified because it is self-tracking. When you pass the Person object back to the data tier, the object can easily relay what’s changed and the context can use this to persist the object.

Of course, this means that the object is not POCO any more because it has logic to track changes within itself so there is yet another approach. You can pass the POCO object back to the Entity Framework and attach it to the context which can then do a diff on the object and the original object to determine what’s changed. This requires more processing obviously.

Proxy Tracking

Besides diff’ing the POCO entities or using self-tracking entities for change detection, another approach is provided by the Entity Framework 4.0 which is proxy tracking. It provides the benefits of POCO without the performance implications of doing a diff (to check what’s changed each time the POCO object is re-attached to the context) albiet it cannot be used in an n-tier scenario.

If using proxies to track changes, EF sets up proxy classes to communicate with your POCO classes. These proxy classes inherit from the POCO classes and any property getter/setter calls are still made to the POCO class but through the proxy class. This allows the Entity Framework to stay in sync with entities at all times. You do however need to be a bit careful if you are going to serialize these objects because the resulting output could be a proxy object (though easily remedied by calling something like EFPocoAdapter’s ProxiesToPoco() equivalent in EF 4.0).

Conclusion

This is going to be a big release for EF to bring it in line with the other major ORMs out there. The MVC community right now favors Linq to SQL but hopefully we’ll see more ASP.NET MVC + Entity Framework projects coming out.

1. Properties allow access modifiers on getters and setters

   public string Name { get; private set; }

   which makes the property read only publicly but read/write privately.

2. Properties can be virtual. Fields cannot be overwritten.
3. Properties can be declared in an interface. Fields cannot.
4. Properties provide fine-grained control such as data validation or simultaneously logging to a file.
5. .NET (by design) uses properties for data-binding making them necessary.
6. Changing a field to a property (or vice-versa) breaks binary compatibility, thus it’s a breaking change (requires recompilation). It may be desirable to use properties for future extensibility instead of thinking YAGNI.
7. Moving from fields to properties breaks source compatibility. For example, if you are using reflection on any of the fields which have since been changed to properties, then the code for reflection will need to be updated (PropertyInfo vs FieldInfo). Similarly, serialization will also break.
8. Since properties can contain some additional logic, they can throw arbitrary exceptions. Fields cannot.
9. Break points can be set on properties making them easier to debug. They can’t be set on fields.
10. Fields can be used for ref or out arguments but properties can’t.
11. Properties can do lazy loading

    public string Name {
        get {
            if (this._name = null) LoadName();
            return this._name;
        }
    }
    

These reasons should be good enough to persuade you to use properties instead of fields.

I came across the JSMin task for NAnt which was pretty good but not as good as YUI Compressor. I came across a .NET C# port of the JAVA based YUI Compressor and also found a custom task for it but no DLL. I threw the two together with the latest .NET port of YUI Compressor and put it up on my projects for download under NAnt task for YUI Compressor.

1. Persistence Ignorance
2. Single Responsibility Principle
3. Domain Driven Design
4. An Interim Solution

I previously published a JSON / POX Filter for MVC developers working with RESTful services. It works really well in that it allows a Controller Action to speak two additional languages (JSON and XML) other than View rendition without requiring any extra modifications. Everything was fine until I pulled out Linq to SQL and plugged in Entity Framework and got an education on a variety of issues with the framework.

Persistence Ignorance

Serializing objects within the Entity Framework is a common enough scenario that I expected to work around it farily easily. More so because the serialized objects only contained some additional undesirable key/value pairs that I did not expect. This is when I first got introduced to Persistence Ignorance.

In the Entity Framework an object generated from the Persons table for example contains not only the properties and relationships of that table (such as Age and Name) but also has additional properties used for tracking changes to the object (such as EntityState). In my scenario, serializing the entity object ought to have resulted in a plain object representation (JSON format shown):

// Plain Old CLR Object
{"Id":1, "Name":"John"}

But instead I saw this:

// Entity Object
{"Id":1, "Name":"John",
 "EntityState":2, "EntityKey": {"EntitySetName":"Persons",
    "EntityContainerName":"PersonEntities","EntityKeyValues":
     [{"Key":"Id","Value":1}],"IsTemporary":false}}

In laymen’s terms Persistence Ignorance is a design principle which suggests that the underlying object hide the details of how it is persisted so you can ignore it and work with a simple object. The term “ignorance” suggests that this behaviour be encapsulated which is a tenet of Object Oriented design.

Single Responsibility Principle

Instead, the Entity Object has additional properties used by the Entity Framework for managing data persistence. An object that plainly represents the Person table and does not contain any additional service-level properties and functions is called a Plain Old CLR Object or POCO. The Entity Object violates the Single Responsibility Principle because other than representing a Person it takes on the additional responsibility of managing data persistence.

Albeit, this makes it very convenient for the Entity Framework to persist the object in the database if, for example, you make modifications to the Person object and save it back to the database. Because the state information is stored within the object itself, the Entity Framework easily knows if the object has changed (by looking at the EntityState property) and what changes were made. It can then update the appropriate fields in the database. Even though this makes things easy for the Entity Framework, it is clearly a big second responsibility tacked on to what should be a plain old Person object. Besides, developers need not be confused by nor concerned with lower level implementation details of state and persistence. Consequently, the Entity Framework recognizes and intends to fix this in Version 2 which will support POCO and Persistence Ignorance.

Domain Driven Design

Lack of POCO objects means that developers are left dealing with an Entity Object and while for me this started off with a naive problem of serializing a Person object, the actual issue has further implications. My over simplified understanding of Domain Driven Design is that domain objects should be Plain Old CLR Objects and should encapsulate only domain logic. So for example, if you are building a warehousing application, the objects used to represent the warehouse domain should only encapsulate functionality within the warehouse (such as orders, storage and delivery). Anything more in the objects (such as database persistence) and the application breaks the Domain Driven Design model. It gets much harder to manage or extend, and Separation of Concerns is lost. For further discussion Ian Cooper’s article on Entity Framework and Domain Drive Design provides an interesting and insightful background on this issue.

An Interim Solution

The EFPocoAdapater is just what the name suggests — a POCO adapter for the Entity Framework which solves the issues outlined above. The EFPocoAdapter currently serves as a sort of staging platform for supporting these scenarios until they become available in version 2 of the Entity Framework, at which time EFPocoAdapter will be made obsolete.

We wanted to make you aware that we have modified our Terms of Service: To more effectively serve our Gallery members, we have adjusted our photo-storage policy to align with storage usage.

How this affects you.

Once you begin storing photos at the Gallery, you must make the following purchases to continue such storage:

- Members with photo storage of 2 gigabytes (GB) or less must make annual minimum purchases totaling at least $4.99.

- Members with photo storage exceeding 2GB must make annual minimum purchases totaling at least $19.99.

Failure to meet this requirement may result in your photos being deleted from the Gallery.

The recession has hit Kodak (NYSE:EK) quite hard as is clearly apparent from their stock price for the prior 12 months.

My sympathies to their shareholders, employees and customers alike but unless this is a last ditch effort, I am not sure what they aim to achieve with this move. Those Kodak Gallery users that stay on will do so only because they are coerced into it–pay up or lose the pictures. Those that have backups will probably ditch Kodak with a bad taste in their mouth and unlikely to return. I am not sure how much money they intend to salvage from this move, but it seems like a downward spiral for Kodak. Must be really desperate times.

1. JSON and XML Action Filter Code
2. Usage Example
3. Sample Output

So I just hopped on the ASP.NET MVC bandwagon. As my first task, I undertook custom Action Filters for returning either JSON or XML as determined by the HTTP Request. Fortunately Omar AL Zabir did most of the work for creating a RESTful API with ASP.NET MVC.

JSON and XML Action Filter Code

The following is a filter which makes the whole thing much cleaner. The filter looks for Content-Type headers in the HTTP request. If it matches text/xml then Plain Old XML (POX) is returned and if it matches application/json the output is JSON. This eliminates the need to write separate actions for JSON/XML and Views.

using System;
using System.Web;
using System.Web.Mvc;
using System.IO;
using System.Xml;
using System.Text;
using System.Xml.Serialization;
namespace AleemBawany.ActionFilters
{
  public class JsonPox : ActionFilterAttribute
  {
    private static UTF8Encoding UTF8 = new UTF8Encoding(false);
    public override void OnActionExecuted(ActionExecutedContext filterContext)
    {
      // setup the request, view and data
      HttpRequestBase request = filterContext.RequestContext.HttpContext.Request;
      ViewResult view = (ViewResult)(filterContext.Result);
      var data = view.ViewData.Model;
      String contentType = request.ContentType ?? string.Empty;
      // JSON
      if (contentType.Contains("application/json"))
      {
        filterContext.Result = new JsonResult
        {
          Data = data
        };
      }
      // POX
      else if (contentType.Contains("text/xml"))
      {
        // MemoryStream to encapsulate as UTF-8 (default UTF-16)
        // http://stackoverflow.com/questions/427725/
        using (MemoryStream stream = new MemoryStream(500))
        {
          using (var xmlWriter =
            XmlTextWriter.Create(stream,
              new XmlWriterSettings()
              {
                // Plain Old XML (no XML headers)
                OmitXmlDeclaration = true,
                Encoding = UTF8,
                Indent = true
              }))
          {
            new XmlSerializer(data.GetType()).Serialize(xmlWriter, data);
          }
          filterContext.Result = new ContentResult
          {
            ContentType = "text/xml",
            Content = UTF8.GetString(stream.ToArray()),
            ContentEncoding = UTF8
          };
        }
      }
    }
  }
}

I suggest you get the code directly through JsonPoxFilter.cs in my SVN repository. It will be updated if I make any improvements.

Usage Example

To use this code in your Controller Action, you simply need to decorate it with the [JsonPox] attribute:

// Depending on HTTP Content-Type header
// this returns JSON, XML or the default View

[JsonPox]
public ActionResult Index()
{
        ArrayList stuff = new ArrayList();
        stuff.Add("Hello World");
        stuff.Add(999);
        stuff.Add(1.0001);
        ViewData.Model = stuff;
        return View();
}

Sample Output

If Content-Type: text/xml HTTP header is present the output is:

<ArrayOfAnyType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <anyType xsi:type="xsd:string">Hello World</anyType>
  <anyType xsi:type="xsd:int">999</anyType>
  <anyType xsi:type="xsd:double">1.0001</anyType>
</ArrayOfAnyType>

For the HTTP header Content-Type: application/json the output is:

["Hello World",999,1.0001]

And if neither of those headers are present, the default View is returned.

Once again, if you intend to use it, get the latest bits for JsonPoxFilter.cs here instead of copying the above code.

Recently, I wanted to downgrade my account from a reseller to a shared hosting plan because I no longer resell hosting. After 3 chat sessions which all resulted in tickets being opened, another 3 tickets being opened by me personally and a call to their 1-800 number (which was not received so I had to leave a message), I was forced to switch.

It’s annoying enough that they don’t care about my domains or my requests but not caring to response is downright horrendous. Maybe it’s because my request is for a downgrade to a cheaper plan which doesn’t bode well or maybe they are going through their bi-annual internal reorientation.

There are two issues with tagName:

• In all versions of IE, tagName returns ! when called on a comment node
• For text nodes, tagName returns undefined where as nodeName returns #text

nodeName has it’s own set of issues but they are less severe:

• IE 5.5 returns ! when called on a comment node. This is less harmful than tagName which suffers from this behaviour across all versions of IE
• IE 5.5 doesn’t support nodeName for the document element or for attributes. Neither of these should be a concern for most practical purposes but should be kept in mind in any case
• Konqueror ignores comment nodes when using this property. But then again, Konqueror, along with IE 5.5 is not an A-grade browser

So for most practical purposes stick to nodeName due to its support for a wider range of scenarios and potentially better forward compatibility. Not to mention that it doesn’t hiccup on a comment node, which has a tendency to creep into code unannounced. Don’t worry about IE 5.5 or Konqueror as their market share is near 0%.