Question

I’m working on an ASP.NET web application that uses a lot of JavaScript on the client side to allow the user to do things like drag-drop reordering of lists, looking up items to add to the list (like the suggestions in the Google search bar), deleting items from the list, etc.

I have a JavaScript “class” that I use to store each of the list items on the client side as well as information about what action the user has performed on the item (add, edit, delete, move). The only time the page is posted to the server is when the user is done, right before the page is submitted I serialize all the information about the changes that were made into JSON and store it in hidden fields on the page.

What I’m looking for is some general advice about how to build out my classes in C#. I think it might be nice to have a class in C# that matches the JavaScript one so I can just deserealize the JSON to instances of this class. It seems a bit strange though to have classes on the server side that both directly duplicate the JavaScript classes, and only exist to support the JavaScript UI implementation.

This is kind of an abstract question. I’m just looking for some guidance form others who has done similar things in terms of maintaining matching client and server side object models.

Answer 1

Makes perfect sense. If I were confronting this problem, I would consider using a single definitive description of the data type or class, and then generating code from that description.

The description might be a javascript source file; you could build a parser that generates the apropriate C# code from that JS. Or, it could be a C# source file, and you do the converse.

You might find more utility in describing it in RelaxNG, and then building (or finding) a generator for both C# and Javascript. In this case the RelaxNG schema would be checked into source code control, and the generated artifacts would not.

---

EDIT: Also there is a nascent spec called WADL, which I think would help in this regard as well. I haven’t evaluated WADL. Peripherally, I am aware that it hasn’t taken the world by storm, but I don’t know why that is the case. There’s a question on SO regarding that.

---

EDIT2: Given the lack of tools (WADL is apparently stillborn), if I were you I might try this tactical approach:

• Use the [DataContract] attributes on your c# types and treat those as definitive.
• build a tool that slurps in your C# type, from a compiled assembly and instantiates the type, by using the JsonSerializer on a sample XML JSON document, that provides, a sort of defacto “object model definition”. The tool should somehow verify that the instantiated type can round-trip into equivalent JSON, maybe with a checksum or CRC on the resulting stuff.
• run that tool as part of your build process.

To make this happen, you’d have to check in that “sample JSON document” into source code and you’d also have to make sure that is the form you were using in the various JS code in your app. Since Javascript is dynamic, you might also need a type verifier or something, that would run as part of jslint or some other build-time verification step, that would check your Javascript source to see that it is using your “standard” objbect model definitions.