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?
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:
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
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
I have stored
|show 8 more comments|
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.