.Net Solution Structure for ArcObjects and Geodatabase programming

Question

OK - I understand that this is a bit subjective - but you're the best community forum I've got!

So, we are talking about starting a fresh customisation for ArcGIS or a Windows app using Engine. I often become a little perplexed when trying to create nice clean layers of abstraction between my GUI, business objects and data access layer (geodatabase access).

It often works out like something below:

• The PresentationLayer makes calls in BusinessLayer to get data from database and give back wrapped up in some form of business object - it is never a ValueObject straight fresh from the database.
• In BusinessLayer - I have all my business logic that accesses DataLayer for data from the geodatabase (it gets back data from the geodatabase via ValueObjects - DataLayer also uses this assembly).
• In ValueObjects assembly, this is just a set of objects that map directly to SDE tables and do nothing else.
• Core is where the program starts and shows forms etc.
• Common is just a place to put things that are useful to use here and there, usually static methods etc.

Does this look sane? How do you structure your solutions?

Answer 1

I like very much to talk about ArcObjects and that kind of discussion, but people may not find it suitable here.

Well I always have a project for specific, ArcObjects code only. That means I can reuse these methods and classes anywhere else. (sounds like your Common).

This is how I do it:

• Solution

  • Business Project

    • Models (this is how I name the mapping between features and objects);

    • Repositories

    • Other business code

  • Business Test Project

  • AO Specific Code (I generally call it Company.Project.GIS and it divide it following the main namespaces ESRI has. This project cannot ever never reference the Business Project. If you need to build a geometry aggregator, or a tool that works commonly, build it here, and consume it on the business layer)

    • esriSystem

    • Carto

    • Display

    • Geodatabase

    • Geometry

    • Authentication (this is a custom part, that handles, for example, authentication against a table in a geodatabase - but it could be anything else);

  • AO Specific Code Test Project

  • UI Project

    • Forms

    • Controls

    • Extension

    • Commands

    • Tools

    • Dockables

    • etc

  • UI Test Project

I try to separate UI project from Business Project, but sometimes with legacy code you can't just bring them apart and I always create separate projects for unit testing.

Answer 2

Dave Bouwman wrote a helpful series 5 yrs ago about this. I would be very interested in hearing how his methodology has evolved since then.

Geodatabase Kung-Fu: Geo-Business Objects

Code Generation + Geodatabase = Goodness

.NET Databinding the Geodatabase