Over the last couple of days I’ve been re-arranging the classes in some ArcGIS Server projects to create some utility assemblies, and I thought I’dwrite up a quick post on what I’ve come up with…
Basically I’m looking at server development a little differently after the UC – I’m taking the advice of pushing most of the processing into the SOC seriously. Previously, I was just doing it all in the client (a web service in my case), and was beginning to see performance problems. Anyhow, as most developers, I’m lazy at heart, so if I’m going to write something, I assume I’ll need it again, and if it’s at all generic (or “general” to avoid confusion with the new .NET 2.0 treats), I slap it into utility classes. Woo.
Anyhow, my thinking so far it to have two general utility assemblies:
Sanborn.AGS.Utilities.ClientSideThis has things used on the “client side” of the picture. By “client side”, I mean “not in the SOC”.
This mainly has functions related to the server ( CreateContext(HostName, ContextName) as IServerContext ) and some Map related that return Layers based on their Dataset Name. Certainly not comprehensive, but it’s a start.
Sanborn.AGS.Utilities.SOC
This holds handy things best done in the SOC.
This currently has things related to geometries, selections, raster extraction and some geodatabase stuff.
I also have two more assemblies which contain the unit tests for these Utility assemblies. My previous habit was to follow the “zen” of Test Driven Design, and had my tests directly in my classes, but since these tests rely on specific contexts running on specific machines, I did not see the use of shipping them with my code.
Since something here needs to be specific to the client, I’ve got another assembly which holds the custom “SOC side” logic required by this project. And finally, I have the web service itself. Seems to be working pretty well, despite the profusion of projects!
