This post is the first post in my ArcObjects series.
“I cried because I did not have an office with a door, until I met a man who had no cubicle.” Dilbert
(Introduction to the Joy of Work by Scott Adams)
Back when I started in my current place of employment I was given a month to learn Silverlight (I came from a WinForms background). After a week of reading a dry book I wanted to look into the team’s code – and discovered the Horror!
The usage of ArObjects was everywhere and not just that there was a file named SdeUtilities.cs that was copied around that contained functions for insert/update/delete data using ArcObjects.
Why is that such a Horror?
In my previous job I was in charge of a Framework that encapsulated all ArcObjects except for classes/interfaces that implemented IGeometry (such as IPoint, IPolyline etc.). The idea there was that some programmers do not have ArcObjects background but know the geometry of the entity they want to save/load and with that Framework in place they could just use it!
But using only helper methods (the SdeUtilities) insured that any programmer that needed to work for the team has to know ArcObjects, or fall in it’s pitfalls (such as not releasing a cursor, multithreading problems and much more).
Now the Framework I built is not up to the standards of NHibernate or Entity Framework, but it gets the job done. And it has both Unit Test and Coded Integration Tests (something that sometimes I wonder about ArcObjects in general).
For some unknown reason, I find the quote from Scott Adam’s book Joy of Work (a book I highly recommend) appropriate here: “I cried because I did not have an office with a door, until I met a man who had no cubicle.”
Real Example
Imagine the following scenario: you as a programmer need to write code for tracking down sheep in the following way: insert a point location to SHEEP_HISTORY_LOCATIONS, update the point in SHEEP_LOCATIONS and update the geometry in SHEEP_TRACK (a polyline layer). I actually had these actual functionality in both my previous and current jobs (just not with sheep…). What will you have to do using ArcObjects?
1. Initialize the ArcEngine license
2. Get the workspace from the connection string
3. Update the IFeature in SHEEP_TRACK (Get the IFeature from SHEEP_TRACK (and it’s shape IPolyline), and add a point)
4. Update the IFeature in SHEEP_LOCATIONS (Get the IFeature from SHEEP_LOCATIONS and change the point shape)
5. Insert an IFeature to SHEEP_HISTORY_LOCATIONS (insert a new feature with the correct fields)
The example code can be found here (in my CodePlex project). It is in the usual style of ESRI’s examples – in a word ‘messy’. As can be seen this code is neither readable nor testable. Using my Framework the code could look as easy as:
- public void AddSheepLocation(int code, IPoint location)
- {
- var sheepTrack = SheepTrackDal.Instance.GetByCode(code);
- var track = (IPolyline) sheepTrack.Geometry;
- track.AddPoint(location);
- SheepTrackDal.Instance.UpdateLocation(new KeyValuePair<String, object>("Code", code), track);
- SheepLocationDal.Instance.UpdateLocation(new KeyValuePair<String, object>("Code", code), location);
- SheepHistoryLocationDal.Instance.Insert(new SheepHistoryLocation { Code = code, ReportTime = DateTime.Now, Geometry = location});
- }
As opposed to ~100 lines of code this is actually readable… But lets go over it:
line 3: getting the SheepTrack entity from the DB
line 4-5: Getting the geometry and adding a point
lines 6-8: saving the data.
As you can see the only ArcObjects directly in use here are IPoint and IPolyline (which implement IGeometry).
Note: the red words are because I haven’t actually implemented the sheep classes and Dals (Dal = Data access layer) but that will come in the one of the next posts.
Are there no alternatives to ArcObjects?
At this point in time you must be thinking to yourselves “This is too much work! There must be an alternative.”, and you are right. You don’t have to use ArcObjects (even if you want to use ArcGIS Server). The solution is using an ESRI supported Spatial Database such as Oracle or Microsoft SQL Server 2008. Using those DBs you can register the tables in the SDE but handle all the insert/update/delete yourselves (like NHibernate Forge formerly NHibernate Spatial). You should be advised that Linq2SQL and Entity Framework have little to no support for Spatial types (though there is a workaround).
Using this Spatial Types is also a great workaround for people without ESRI license such as Engine, Editor or Server. Without these licenses the options of insert/update of Spatial Data in SDE is non existing (assuming you use an actual DB and not a File DB).
Next: ArcObjects: Getting Started
