Differences between revisions 13 and 15 (spanning 2 versions)
Revision 13 as of 2009-12-17 16:36:42
Size: 3249
Editor: 24-183-238-75
Comment:
Revision 15 as of 2009-12-17 16:40:33
Size: 3451
Editor: 24-183-238-75
Comment:
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
'''Fields''' are loaded from the database based on app.config setting and are stored in a UI local Dictionary<int,FieldData> that maps the Field Identifier with an object for the specified field. '''This object is the top of the controller objects that we can access from the UI.'''
'''Fields''' are loaded from the database based on app.config setting and are stored in a UI local Dictionary<int,FieldData> that maps the Field Identifier with an object for the specified field. '''This Dictionary object is the top controller object and may be used to initiate control functionality from the UI directly.''' NOTE: For items that are bound (using a BindingSource) it is not always necessary to traverse the controller hierarchy via the ''fields'' Dictionary Object.

Programming the Object Model

The next few sections discuss the overall approach to programming the database interface, business objects and back end systems. For a second iteration, we are considering the following technologies to clean up the implementation:

Visual Design Elements

We are using Windows Forms to create an interface with Menus and multiple layers of embedded tabbed panels. When the application starts the UI loads the following information:

Site is loaded from app.config

Fields are loaded from the database based on app.config setting and are stored in a UI local Dictionary<int,FieldData> that maps the Field Identifier with an object for the specified field. This Dictionary object is the top controller object and may be used to initiate control functionality from the UI directly. NOTE: For items that are bound (using a BindingSource) it is not always necessary to traverse the controller hierarchy via the fields Dictionary Object.

Object to Database Integration Model

We are building a Model View Controller (MVC) application.

Our model is contained in a Dataset object ArchDataset.xsd along with the ancillary host of helper objects. Although these are very complex, they are standard elements and perform in expected ways. We will not cover them in detail. To find out more information about this particular model, see the ArchaeologyProject/DataModel.

The view is contained in [Name]Controls.cs and Forms files. These are organized under the directories Forms, FormControls, and Controls. These hold the visual components that display data and contain visual elements that allows the user to interact with that data. Currently we are using windows forms. In the future we would like to move to WPF.

The controller components glue the underlying model to the views and make extensive use of the Dataset paradigm to speed the development process. This is the most complicated part to be programmed. And deserves the greatest attention. In a moment of weakness these were seen to work more with the model than the view and are organized under the Data folder.

Controller

The controller interacts with both the Model and the View in the following ways: Creating new forms, Loading Filled Forms and Saving Changes to forms.

Creating New Locus Forms

New forms are created by menu selection while viewing a square. The menu creates a LocusDataEarth, LocusDataArchitecture or LocusDataInstallation object. These are controller objects. The tab control is acquired and a tab page added with the appropriate labels. Then the controller object provides a ctrlPannel that is placed on the Tab. The control pannel provided by the controller object is linked in such a way that interaction with it, is reflected in the controller object and as needed back to the database.

ArchaeologyProject/ObjectModel (last edited 2010-04-06 21:47:57 by 24-183-238-75)