views:

55

answers:

1

I'm not even sure if I worded the question right, but I'll try and explain as clearly as possible with an example:

In the following example scenario:

1) Take a class such as this:

public class foo
{
   public string firstName {get;set;}
   public string lastName {get;set}
}

2) Serialize that into JSON, pass it over the wire to the Browser.

3) Browser de-serializes this and turns the JSON into a JavaScript object so that you can then access the properties like this:

var foo = deSerialize("*******the JSON from above**************");
alert(foo.firstName);
alert(foo.lastName);

What if now a new developer comes along working on this project decides that firstName is no longer a suitable property name. Lets say they use ReSharper to rename this property, since ReSharper does a pretty good job at finding (almost) all the references to the property and renaming them appropriately.

However ReSharper will not be able to rename the references within the JavaScript code (#3) since it has no way of knowing that these also really mean the same thing. Which means the programmer is left with the responsibility of manually finding these references and renaming those too.

The risk is that if this is forgotten, no one will know about this error until someone tests that part of the code, or worse, slip through to the customer.


Back to the actual question: I have been trying to think of a solution to this to some how strongly type these property names when used in javascript, so that a tool like ReSharper can successfully rename ALL usages of the property (and accurately)?

Here is what I have been thinking for example (This would obviously not work unless i make some kind of static properties)

var foo = deSerialize("*******the JSON from above**************");
alert(foo.<%=foo.firstName.GetPropertyName()%>)
alert(foo.<%=foo.lastName.GetPropertyName()%>)

But that is obviously not practical. Does anyone have any thoughts on this?
Thanks, and kudos to all of the talented people answering questions on this site.

This is kind of an experiment of mine, so any suggestions would be welcome.

+1  A: 

Most refactoring tools have a mode where they examine a fulltext search of the codebase to find usages. (I know ReSharper has that option.) That would solve at least part of the problem. Comprehensive integration tests would also go a long way to solving some of the issues you mention.

Another way to solve the issue would be to couple less tightly your wire format (i.e. the JSON) and your type hierarchy.

DDaviesBrackett
Yes ReSharper does have that option, but it was not able to find it in my case. Also, even if does, it can confuse other usages of that string even though it has nothing to do with it. I agree with you about integration tests, but I wanted to try and solve the problem at the source rather than waiting for a test to reveal the issue. Not a big deal, this is more of an experiment.
Roberto Sebestyen
Then I'll stand by advice on the last line: rather than coupling your JSON to your type system, invent a separate convention for the JSON that both the C# and the JS understand, and that will only be affected when someone makes a deliberate change to it.
DDaviesBrackett
Right but when someone makes a deliberate change to it, would they not will find themselves in the same sort of scenario I pointed out? Especially if it is used in many places spread all over?
Roberto Sebestyen
yes, but then at least they'll know they've changed the JSON interface and they'll (presumably) know they have to make that change in all the affected places.
DDaviesBrackett