According to best practices is it a bad idea to cache features and geometries inside business objects? If it is bad, what is the alternative way?
References to features may be replaced with their Ids, but what about geometries?
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It only takes a minute to sign up.Sign up to join this community
In general this shouldn't be a problem but there are some objects in the ArcObjects library that you want to be very careful about managing their lifetimes so that you don't tie up critical resources or keep locks on database tables for extended periods.
Among lots of other good info, in this thread James MacKay lists some of the types of objects you should take special care with:
- Datasets, i.e. tables, feature classes, feature datasets, rel. classes (but excluding name objects)
- Workspaces (inc. versions, if you're connecting to multiple versions of an enterprise GDB at once)
- Rows, features and attributed relationships
- Row buffers and feature buffers
If you are using .NET then you should be aware that it is a garbage-collected environment, and COM objects are not necessarily released as soon as they go out of scope, but can linger on until application shutdown unless you explicitly release them, call
GC.Collect() (not recommended), or the GC finally decides to clean them up on its own. For more info see Releasing COM references in the ArcObjects SDK help.
I think storing row IDs instead of rows themselves is a good idea, but you should be okay storing geometries that you create as long as memory consumption is not a problem. As @Ragi mentions below, if the geometries are coming from a recycling feature cursor, be sure to use
IFeature.ShapeCopy to create a clone of the feature's geometry. I am also assuming your business objects will not need to be serializable, which could complicate matters.
I have stored
IFeatureClass references (which keep connections open to their source workspaces) in business objects and implemented logic to specifically release them as soon as they were no longer needed (see Implementing a Dispose Method, if you are using .NET, for the MS-recommended dispose pattern, and IDisposable: What Your Mother Never Told You About Resource Deallocation for a better understanding).
You do not describe in detail what exactly are your business objects. It is a largely overloaded term and many people tend imagine very different things.
Given that your business objects are the same as domain objects in the sense of traditional domain-driven design, I am gonna suggest the exact opposite of blah238's answer (even though it contains a lot of valuable information) - do NOT keep references to geodatabase objects in your business objects.
The rationale behind this suggestion might not be applicable for the simplest applications, but please bear the following points in mind:
Now, again, validity of all of these points largely depends on your particular scenario and needs. Holding onto ArcObjects is obviously not prohibited and I do that myself on occasions. You just need to be aware of the implications, of which there are many. As I tried to hint, some of these are technically purely ArcObjects-related, some are more of a higher-level software design nature.