У великому проекті нам вдалося досить добре ізолювати код ArcObjects від нашої бізнес-логіки. Я б сказав, що це взагалі шлях, а не намагатися знущатися над усім, навіть якщо це можливо, використовуючи глузуючі рамки, щоб отримати деякий шлях.
Запитайте себе, чому саме ви відчуваєте потребу знущатися. Як правило, це через відсутність абстракції. Подумайте про невеликі обов'язки і мінімізуйте поверхню величезного, потворного монстра ArcObject. Уникайте перетягування типів ArcObject лише тому, що десь потрібен їх аспект.
Я можу навести один конкретний приклад з нашого проекту. Частина коду, здавалося, залежала від IMxDocument. Виявилося, що єдиною причиною було те, що активний погляд потрібно було оновити. Тож ми створили натомість інтерфейс IViewRefresher і працював лише над цим; легко висміювати і тестувати. Крім того, це робить намір коду набагато зрозумілішим і знімає спокусу, щоб хтось почав робити смішні речі з IMxDocument, які вони не повинні були робити, тому що все, що ми хотіли зробити тут, було оновити. Таку ж вправу можна виконати з великою кількістю коду ArcObjects.
Крім того, ми перетворили весь доступ до класів функцій у безпечних обгортках типу, знову надаючи макетний код, що захищає бізнес-код від ArcObjects.
Ми навіть не використовували геометричні типи ArcObjects, але в даний час ми дозволяємо використовувати ці інтерфейси безпосередньо в нашому коді. (Однак, лише знання інтерфейсу дозволено, і всі моменти геометрії використовують нашу власну фабрику геометрії.)
Підводячи підсумок, я не переслідую глузування, але рекомендую глузувати з іншого рівня абстракції, ніж ArcObjects.