Why ShapeFile class does not have public read-only property CoordSysReadFromFile?

Topics: Data Access
Apr 4, 2007 at 8:22 AM
The property is necessary for serializing this class and other tasks.

I offer to add following code to ShapeFile.cs:

Line 251:

public bool IsCoordSysReadFromFile
{
get { return _CoordsysReadFromFile; }
}



Sorry my english :)
Coordinator
Apr 4, 2007 at 8:47 AM
The reason is that this property is set by an internal mechanism to the ShapeFile provider. If there is a PRJ file, it should be true. Setting it to true won't create the file, so it would be an error if a set accessor existed. Finally, a data provider is not meant to be serialized. It's designed to be created, opened, queried and closed within a well-defined context - remoting or persisting isn't part of it's scope.
Apr 4, 2007 at 9:18 AM

codekaizen wrote:
The reason is that this property is set by an internal mechanism to the ShapeFile provider. If there is a PRJ file, it should be true. Setting it to true won't create the file, so it would be an error if a set accessor existed.


I offer make this property read-only!


Finally, a data provider is not meant to be serialized. It's designed to be created, opened, queried and closed within a well-defined context - remoting or persisting isn't part of it's scope.


I create Data Provider classes as usual using new statement. But what should I do to save settings of DataSource(ShapeFile example: FileName, CS and other)?


Sorry my english.
Coordinator
Apr 4, 2007 at 10:24 AM
Oh, sorry, I see what you are saying now - you would like to add that property.

I wonder if it would be useful. The data source parameters are usually just a set of key-value pairs or a file name. That's all you need to persist. In the case of a shapefile, just the shapefile path and file name. Due to the specification of the shapefile, you can always tell if there is a file-based coordinate system by observing if there is a PRJ file in the same directory with the same name. If so, the shapefile provider sets the SRID property on the data source. If not, SRID is -1.

Hope this helps...
Apr 4, 2007 at 1:14 PM

If so, the shapefile provider sets the SRID property on the data source. If not, SRID is -1.


I'm not sure - the provider don't set SRID, but set CoordSistem(chset19234)-it's bug either, IMHO!

But it isn't important:
I can set any CS for the data source. When I serialize DataSource,I'm necessary to now if CS was read or was setted manual.
Therefore the property must be public, imho.

Sorry my english.


Apr 4, 2007 at 1:56 PM
For serialization one more parameter needed - FileBasedIndex.
:)
I offer to add following code to ShapeFile.cs:

Line 250:
public bool FileBasedIndex
{
get { return _FileBasedIndex; }
}
Coordinator
Apr 4, 2007 at 5:02 PM
Oh, ok. I see where you are going with this now. You'd like more of the internals of the Shapefile provider exposed so you can observe it.

Perhaps you could give me a bit more story around what you are doing. There might be a better way, like an observer pattern, or provider state interface, which could generalize a bit, and keep the provider well encapsulated. Exposing public properties on providers, which are meant to have a consistent interface, is a code smell.
Apr 4, 2007 at 7:03 PM
Edited Apr 4, 2007 at 7:08 PM
Ok. I'm developing serializer for ShapeFileProvider(you can name it "settings saver").

If you are follower of patterns, you should know, what if a class has constructor with required parameters, this parameters (or its analogs) is necessary to serialize (or save settings of) this class.

I would not like to expose internals of provider, but I don't know, how I can correctly save its state!

Can you post a sample?


Sorry my english.
Coordinator
Apr 4, 2007 at 9:31 PM
I don't think you really want to take this approach. Relying on the provider to be the authority for the settings is not what it is meant to do. The reason for this is that the provider only receives it's settings from external objects - the shapefile data itself or the layer manager, which tells it which filesystem file to use and whether to use a file-based spatial index. These settings come from whatever layer manager you write, and that is what should be getting serialized. I'd go further and recommend using the System.Configuration classes to make a set of configuration classes which can leverage the excellent .Net 2.0 configuration system. You can then drive the configuration which will instruct your layer manager to create the correct ShapeFile provider (and any other provider).

As an aside, if I were developing a serializer and didn't have access to it's internals, I'd encapsulate the seralizing know-how in a Visitor which can do reflection. Sure, it breaks the public interface contract, but you're breaking encapsulization anyway - better to confine it to a single class with just that responsibility. And performance isn't really an issue when serializing, since 1) there aren't all that many ShapeFile providers instantiated at any one time, and 2) the order of magnitude longer reflection takes than direct property access is dwarfed by the several-to-many orders of magnitude longer any subsequent I/O will take. In almost every case, a Reflecting Visitor is a good way, if not the best way, to go. This is actually what .Net gives you out of the box when you use binary serialization.