A Geographic Nightmare
Oren Eini talks about nightmare platforms, and so I got the urge to talk about my issues with the GIS platform we are using - ESRI ArcGIS Server 9.2. First, let me state that this is a very powerful (and expansive) product. In fact, there is practically no other product that offers the features and capabilities you get with GIS Server. You can do practically anything geographic/mapping related with it.
The product was built in a way so that by default, almost anyone can create maps and publish them in a web application or a web service. ArcGIS Server is great if all you want is to create maps with ArcMap (ESRI's desktop application that you use to, well, create maps), use Visual Studio to create a web-page from a template, and use that web-page to let clients view the map. Here is where the trouble begins for us developers. Thing is, if you want to create a real application, that is never enough.
The ArcGIS Server API for working with web applications, is called the Web ADF, and is composed from a host of server controls and libraries. I am sorry to say, that it is a horribly designed, badly documented piece of API. In other words, it sucks pretty bad. Now, I would be a bad sport if I didn't give a few example, won't I?
Let's start with the server controls. What ESRI wanted you to do is drag and drop some controls on a web-page and then go through some wizards to configure the controls. That would be things like, the server address to connect to, the name of the map to show, etc. Now, if you wanted to do something as simple as letting the user change the map he is currently viewing, that should be as easy as changing a property on the Map control, right?
Well, wrong. You have no idea how much trouble we had to go through in order to accomplish this simple task, only for our solution to be broken again upon installation of Service Pack 1 (by the way, the service pack count for ArcGIS 9.2 has already reached 4). We had to solve this issue by browsing reflector for the source code, and then try to find out exactly which code we have to run in each of the Map control life-cycle stages in order to get the damned thing to work. Unfortunately, the release version has its DLLs all obfuscated, so we actually had to go and install the Beta version on another PC, so we can reflect the DLLs whenever we encounter a non-solvable issue. How's that for a nightmare?
The drag-and-drop suckiness doesn't end here. There is a control, for example, that's called SearchAttributesTask. Now this control accepts a collection of layers and fields to search in (you type "bla" and you get to see all the buildings whose name contains "bla"). Now, guess what is the type of the property SearchFields for SearchAttributesTask? No, it's not a LayerFieldCollection, or something. It's a string. Yep, the control comes with a nice designer that serializes your choices to something like: SearchFields = "Buildings:::Name:::Size^^^Houses:::Area^^^...". In order to programmatically change the fields you want to search in, you would have to go and write your own code to create this string serialization, which we did.
The rest of the API is riddled with bad design choices and bugs. Weird exceptions get thrown. You find out that there are 5 different classes that are called Converter in this API, in 5 different namespaces, which in some situations can definitely be used together. Documentation for most methods is something like: Map.GetFunctionalities - "Returns the functionalities of the map." Oh really? Now I couldn't guess that on my own. I should mention that since the initial release the documentation has improved a lot, but it is still no paradise. Recent documentation for this method (added since Service Pack 2, if I am not mistaken), explains that it returns a collection of IMapFunctionality. So why, why oh why, does this method have a return value of IEnumerable? This is a .net 2.0 only library, for pit's sake, they can use generics. And they do, in many other places. Here, they don't. This kind of API inconsistency can drive a man insane, I tell you.
Now, you could decide to skip the ADF, and go right ahead and use the underlying ArcObjects - lower level COM objects that are pretty much the base of every ESRI software, including the Web ADF. Many things will require you to do this anyway, since only ArcObjects expose the full power of ArcGIS. Using ArcObjects feels a lot more consistent. It is terribly annoying to use, but at least in a consistent way. This is an API, as all COM API's, I venture, that relies on interfaces. A lot of interfaces. In fact, in order to accomplish a simple thing as adding a feature to a layer, you might have to get familiar with something like 8 different interfaces. Many times you are working with just the one object, which you have to cast as different interfaces in order to access specific methods (I believe the COM term for this is Query Interface).
Now COM is COM, can't really come complaining to ESRI, right? Well, watch me. For the amount of money an ArcGIS Server license costs, a .NET developer like me could very well expect a decent .NET API to work with. The Web ADF is a .NET API, but it is hardly as powerful as ArcObjects are, nor is it any kind of decent.
To conclude, I would say that ArcGIS Server 9.2 might be a great, easy to use product for some users. But if you're a developer that wants to create kick-ass, cutting-edge GIS stuff with it, you're in for a world of pain.