Seeking opinions on project design .NET and Compact Framework

[paron]

We have a number of inspectors who go into the fields (far from any network connection), inspect culverts, and record the results of their inspections using PocketPCs. Given the PocketPC keyboard (none), it is essential that as much data possible be pre-entered. When they get back in, the inspection data goes to the engineer, who vets the results and then puts them into our SQL Server db.

I thought of doing it in a daily cycle like this:

[ul][li]Inspectors desktop app: SQL Server data =>"culvert" data [/li][li]Inspectors PocketPC app: Load "culvert" data, add "inspection" data to some culverts[/li][li]Inspectors desktop app: save changed "culvert" and new "inspection" data to the LAN[/li][li]Engineer's desktop app: load "culvert" and "inspection" data from LAN, update SQL Server[/li][/ul]

I had it about 2/3 coded in Python/XML when the network admin decreed ".Net". .Net has so many parts that I don't know where to begin!

[ul][li]I'd like "culvert" and "inspection" object's states to be serialized in XML. Is that a mistake?[/li][li]Python supports several data compression schemes natively -- is there a .NET equivalent?[/li][li]Which .Net technologies should I concentrate on?[/li][/ul]

Ron

 

[paron]

OK, I made a schema for a list of 0..many Culverts, each of which has 0..many Inspections. Then I ran xsd.exe and autogenerated classes for XmlSerializer. Now I need to add methods so that the Culvert object can have attributes set by the usual means as well.

There are all kinds of warnings at the top of the autogenerated classes about not changing the code, so I am going to make a copy of the file and erase the warnings and modify it anyway.

If that is possible (is it?), then the cycle looks like: [ul][li]Server app:retrieves data from the db, creates a culvertlist of all our culvert objects and serializes it [/li][li]The inspectors grab the serialized culvertlist off the server and put it in the handheld[/li][li]Inspectors Handheld app: deserializes the culvertlist. The inspectors modify it and come back to the office. Then the app serializes the modified culverts.[/li][li]The inspectors upload a culvertlist of modified culverts[/li][li]Engineers Desktop app: deserializes the inspectors culvertlists for the engineer to review and stuffs the database with the changes he approves.[/li][/ul]

Again, I am just flailing around in .NET -- so if anyone notices me heading down a blind alley, drop me a line, please?

 

[paron]

Ok, now I have written a test form that uses the autogenerated classes from my class library and persists/recovers objects using XmlSerializer. Two things I discovered:

First -- XmlSerializer can't handle jagged arrays (nested 0..many). For one thing, xsd.exe autogenerates the classes incorrectly -- they wouldn't run even if XmlSerializer could handle it. You have to fiddle the "[]"s in the class.

Then XmlSerializer crashes anyway. Our friends in Redmond, in their endearingly disingenuous way, admit that "this is a known behavior" (i.e., it's a bug, but we don't intend to fix it now. Code around it.) So my Culvert objects, which should have 0..many Inspection objects, have 0..1 instead.

XmlSerializer has the least helpful error messages Microsoft ever wrote, which is saying something. Get "XmlPreCompiler" at

http://www.cybral.com/downloads/XmlPreCompiler.zip

for class-by-class, line-by-line feedback.

Second, and a lot smaller -- the autogenerated classes add an attribute that works with any of the numeric types, presumably to handle nulls and differentiate them from "not provided"s. So, if I had a simple VerticalClearance integer element in the .xsd, then xsd.exe would add the following to the class:

/// <remarks/>
public int VerticalClearance;
    
/// <remarks/>
		[System.Xml.Serialization.XmlIgnoreAttribute()]
public bool VerticalClearanceSpecified;

If you don't set the ...Specified attribute to "true", then the attribute is completely absent from the xml that the serializer makes. No <VerticalClearance></VerticalClearance> , no nothing. No problem, either, just something to watch for.

 

[paron]

Now I have written the Server portion of the code, which grabs the records from the db, makes a Culvert object using the data from each record, and serializes them into an xml file for the inspectors to load onto their handhelds.

An observation: datatables have nulls. I found two ways to approach null-handling.

The first is to assign a nullValue in the schema for the dataset using annotations. I didn't like this for a couple of reasons -- first, it plumps up the XML unnecessarily, since all those null values will show up as attributes of the object and get serialized. Second, you are assigning a 0 (or whatever) to a property that really isn't a 0. Then you always have to remember that you've done it so that you don't include it in, let's say, calculating an average.

The second way to handle nulls is to check for them as you are assign the value to your object's attribute, and that's what I chose. I suspect that you very often have some munging to do when mapping db values onto your object's properties anyway, so this is just part of that process. And, you can always set a null value here, if you decide to do so.

 

[paron]

Whoops! Peter Bromberg, at EggHead Cafe shows a nifty way to compress (92%, in one case) Binary Serialized objects and use them as a virtual database in the CF. Or, at least that's what I think I read. Data compression, object serialization, and no SQL Server license needed? Sign me up!

The only trouble is that the classes don't support strongly typed datasets, but I am beginning to think that strongly typed datasets are only useful for working with databases, anyway.

The advantages are such that I am considering re-coding to use these classes from Dr. Bromberg's article, rather than XML Serialization and homebrewing the compression/decompression.

Big Mistake? Not worth the effort to change? Should have started that way to begin with? Still looking for opinions!