MapGuide tidbits: MgFeatureService *is* a data access layer too!

A question we see a lot of on the mapguide-users mailing list is how can we access our external databases in .net/PHP/Java for reporting and things like that (generally in response to a selected feature), which then generally devolves into questions about language-specific data access technologies like PDO/ADO.net/JDBC and it's ilk.

I can't help but think such approaches are unnecessary because MapGuide already has a data access API: MgFeatureService, and it's consistent across .net/PHP/Java.

I think users get the impression that because MgFeatureService is only for spatial data access that it can't be used for regular non-spatial data access, which is untrue.

The only time whether data is spatially-enabled comes into play is if you want to build Layer Definitions off of such class definitions. You'll notice that the Layer editor UIs in Maestro and Infrastructure Studio skip over non-spatial class definitions for this very reason (the lack of a geometry property).

Spatial data is just an extra optional dimension on top of regular data and MgFeatureService does not mandate that the data you're working with must be spatially-enabled. Such class definitions when viewed in a FDO logical schema will simply not have a geometry property, but can still do CRUD operations on such classes via MgFeatureService. Notice how you can still view attribute data for non-spatial class definitions in the feature source preview? That's the MgFeatureService APIs at work.

So the next time you need to access external database in your MapGuide application, ask yourself this question: Am I able to just set up a MapGuide Feature Source to my external database and access this data through MgFeatureService? Because if you can, it will make things much more simpler and make your data access code more portable as being part of the MapGuide API, it will work the same for .net/PHP/Java.

Admittedly, not all external data stores can be accessed cleanly via MgFeatureService. There are some corner cases where an external data store can't be accessed via MgFeatureService due to the physical data store structure not cleanly translating to its equivalent FDO logical schema. For such cases, you can generally workaround the problem with the use of database views and/or FDO schema overrides to either re-configure the problematic tables or weed out the incompatible tables from your FDO logical schema.

So give MgFeatureService some though when you need to access external databases for reporting/etc. It's not just for spatial data access!