Jeff Germain and I have been doing some cool work with the geodatabase, and I’m going to summarize our work over a series of postings. This post introduces the key ideas…

Standard “Business Objects”
In keeping with object-oriented design, most applications are now utilizing classes (business objects) to represent the real-world entities of concern to the application. When it comes time to store these entities in a database, the data access operations are typically bundled into the business objects themselves, or in associated helper classes. The advantages of this model are many, including:

• cleaner code design
• easier maintenance
• encapsulation of data storage logic
• single point for database schema changes
• with .NET 2.0, object data binding is possible (very cool)

There are many design options which take this model to various levels of complexity. You can find all sorts of information about Object Relational Mapping at ORMappers.com

Geo “Business Objects”
Since this is such a nice design pattern, we wanted apply the same logic to the geodatabase. Afterall, you design classes when you design a geodatabase, but the geodatabase API is cumbersome as compared to working with standard business objects. 

To be clear – we’re not talking about replacing IFeature and IRow, after all, you still need to talk to the geodatabase, and that’s how ArcObjects works. But, in order to avoid working with the geodatabase API all over our code, we designed wrapper classes that hide the ArcObjects code behind a nice “business object” facade.

Some might ask – why would you go to all this trouble? The first part is that for large enterprise systems, where they may be 10 or more associated attribute tables related to one feature class, being able to work with a set of business objects greatly simplifies creation of attribute editing forms. And, if designed correctly, these objects could be used in Desktop, Engine and Server applications. The second part is that once you set it up, it’s not much work. Which brings us to…

Code Generation
A nice thing about business objects is that they follow a pattern. And computers can do great things with patterns – like write the code for us. This is what code generation tools bring to the table. A typical code generation tool connects to the database, reads the schema, and creates classes based on code templates. This process takes a few seconds, and can be re-run at any time, and many teams add this as a step in their build process. Depending on the templates used, there are options where the developer can add custom logic which is not over-written when the code is re-generated (via inheritance or partial classes). As you may have guessed, this results in massive time savings when writing applications.

For example, I needed to create an application to edit the tables in a standard relational database (Process table shown above). Using RapTier, I was able to create a complete data access layer in a few minutes. Once that part was done, I was able to very rapidly wire the business objects into an interface, and the application was complete. The image below shows the classes created for the “Process” table. You’ll notice that these objects do not have “Get”, “Save” or “Update” methods. In the abstration model used by RapTier, all these functions for all the classes in the database are in a single helper class.

But this is a Geodatabase…
So, this works well for traditional RDBMS tables, but it’s not going to fly for the geodatabase. First off, you can’t infer all the details of a geodatabase model directly from database schema itself. Specifically, you’d miss thinks like relationships, domains and subtypes. Additionally, if you are working aginst ArcSDE you’ll get all those pesky A, D, F, and S tables. Finally, the code that would be generated would use standard SQL (or stored procs) to insert and update the data. So, clearly we had some issues to work out.

Our Process
We’ve got two large projects on the go right now, and both are going to be subject to many geodatabase schema changes over their life span. To that end, we are working on a process where by we are able to generate business objects (and class extensions) directly from a geodatabase. The diagram below shows how this works, but the high-level steps are as follows:

1. Export the geodatabase schema as Xml
2. Transform that into a simplified Xml
3. Use this simple Xml to generate the code
4. Use object data binding in .NET 2.0 to simplify the form wiring
5. Repeat when the schema changes

In the next installment, I’ll review the process, the business object templates we’ve created and tools we’ve used to so this.

Glad to see that this topic generated some thought, comments and “conversations” around the GIS blogs.

For me, I’m somewhat suprised that GIS people have not jumped on blogs as much as the developer community. In many ways the two are similar – many people are asked to accomplish complex tasks, with many dynamic variables to the problem, typically working in smaller groups or individually. Since I straddle both communities, and I get so much value from the .NET blogs, it is interesting that this has not been widely adopted in the GIS arena.

From the comments and other blog postings, I think that those who are blogging on GIS should make an effort to not only bring more people into blog / rss / aggregator awareness, but to suggest that people start their own blogs so we have wider diversity. In addition, we should compose posts such that they invite conversation. I’ll be trying these approaches, but for those going to the ESRI user conference – try encouraging people to jump into blogging. There are soooo many places where people can start blogs for free, so there is very little barrier to entry, and so much value to be gained – both at an individual level with How-To… and How-Do-You type posts, and as a community with wider participation in the larger conversation.

re: posting in the future – this is just a bit of fat fingers – I’m at a client site this week, and I’m not too great with the track pad on my notebook!

also – I tried to post this comment over at AllPoints, but I’m on an open wireless connection and the IP has apparently been used to spam in the past so I was denied, so I posted it here…

Comment to AllPoints Posting – Chiming in on the Conversation

Hello Adena!

I’m out at a client site this week and I’ve been asking around about blogs in general, and GIS blogs in particular. And it for the most part, GIS people are just beind the adoption curve. Heck – I think that general internet users have yet to really grok blog / RSS / aggregation etc.

I think the main reason I asked the question was that I get so much value out of conversations on niche blogs related to non-GIS development, that I would expect that the relatively niche area of GIS would latch onto this same technology. In both cases, blogging and rss helps bridge gaps between relatively isolated individuals working on complex problems, so it would seem to be a great match up. Maybe we’ll see wider awareness and adoption as ESRI puts more effort into blogging.

Cheers,

Dave