On Geo-Business Objects and Dave’s excellent post
Dave has an interesting post about working with data in a geodatabase but “avoiding” the geodatabase API (Dave Bouwman – Geodatabase Kung-Fu: Geo-Business Objects). I had been grappling with this recently as I start to take on a project that has data in a personal GeoDB and a plain old Access Db. I wanted them to be in the same DB since eventually I would like to move this into SQL server.
The dilema for me is that ArcObjects is not “friendly” when working with just plain tables, as compared to some of the cooler Object-Relational technology out there. I used to use hibernate on my Java projects before doing GeoDB work. I loved the way it removed the need to have SQL anywhere in my code. I was using an Object oriented language and I liked how my compiler helped me to code faster, why would I want to drop into relational world (SQL) where all my interactions were through strings. ArcObjects provides that Object Relational mapping since I work with Objects (IFeature or ITable) to manipulate things in the GeoDB. But there are two problems it presents for me:
1) It is overkill for non-spatial tabular work and is not “standard” in either Java or .NET. Both of these languages have data structures and forms that know how to work with them. You have to basically write code to translate from ArcObjects data to the way you want it to be for representation.
2) To use the GeoDB API you need to purchase a license from ESRI. If all I want is a form to edit some of the tabular data why would I have to buy an Engine (or Engine GeoDB) license so that my code knows how to interact with the GeoDB. It makes sense that people who will be editing spatial information would use ArcGIS to do that work and that they would have a license. But people just typing information into a form should not need a license for that work.
So I asked around and it seems like I can edit tabular data (and even the tabular part of feature data) without using the ArcObjects API. This makes my life much easier. I can still write code to interact with the non-spatial data in the GeoDB that doesn’t use ArcObjects. Please share your stories if you have done this type of work.
It looks like Dave has taken on wrapping the ArcObject calls so that you can isolate the ArcObjects in a layer of your code and then expose more traditional .NET objects higher up. I think this is a great idea if you have the staff and time to pull it off. He earns extra points for using the XML schema exported from Catalog as the basis for code generation. The drawback here is that you still need a license and install from ESRI to work with this code. I know Dave is in Server land so this is not as big an issue for him.
For me, I could have GIS people updating the Features in the geodb (they have an ESRI license) and field people entering non-spatial data (they don’t need an ESRI license on their machine). This is why I want plain .NET or Java interaction with the attribute data. I don’t want to have to install Engine on a machine just so people can enter tabular data in a form.
In the continuum from pure ArcObjects in all your code to Dave’s approach to pure .NET or Java interaction, there has to be some guidelines or more ideas on when it makes sense (size of project, size of staff, how dependent you want to be on an ESRI license…)
I would love to hear what other people are doing. It seems like most bloggers are Server or IMS developers. I have left that area for now and I would love to also hear from Desktop/SDE people. How do you handle this tension between ESRI’s desire for everything to be in the GeoDB and not wanting to use a Sledgehammer to nail together a birdhouse?
On a related note I would also like to hear stories about using a Personal GeoDB for both ArcGIS work and plain old Access work. Has anyone pulled it off successfully? Co-workers here are quite suspicous that I can do this and not hose the GIS data. I want to use the relationships and forms in Access to build the non-spatial data entry piece.