|
Size: 1553
Comment:
|
← Revision 22 as of 2010-04-06 21:47:57 ⇥
Size: 4295
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = C# Programming Object Model = | = Programming the Object Model = |
| Line 5: | Line 5: |
| * SQL CE synchronized to a back end system (See http://www.microsoft.com/sqlserver/2008/en/us/compact.aspx and look for Synchronize corporate data) * NHibernate (http://nhforge.org/Default.aspx) and possibly Fluent NHibernate (http://fluentnhibernate.org/) for database business objects. * SpecExpress framework for specifying property rules validation (http://code.google.com/p/specexpress/) |
* SQLExpress is now and for the forseable future what we are using. * EntityFramework or NHibernate (http://nhforge.org/Default.aspx) and possibly Fluent NHibernate (http://fluentnhibernate.org/) for database business objects instead of hand coding the ObjectRelationalMapping. * SpecExpress framework for specifying property rules validation (http://specexpress.codeplex.com/). Quite frankly, the validation is happening now! As in post Alpha stage, we are now implementing this. See how at [[ArchaeologyProject/SpecExpressImplementation|SpecExpressImplementation]] |
| Line 9: | Line 9: |
| For now we have the Main Form instantiating the Controller Logic, the Controller Logic instantiating the UI as needed and gluing it to the Model. Our implementation blurs the Controller and ORM functions which sit on top of the Dataset object. | |
| Line 10: | Line 11: |
| == Visual Design == | == Visual Design Elements == |
| Line 12: | Line 13: |
| We are using Windows Forms to create an interface with Menus and multiple embeded tabbed panels within tabbed panels. Until we have time, look at the design for more info. NOTE: We are planning to switch from windows forms to WPF. | 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> object that maps the Field Identifier to an object for the specified field. '''This Dictionary object is the top controller object in the UI 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 to initiate a some control functionality. Basically we bind three types of UI objects (click on each one to see documentation about binding the UI object to business object properties): TextBox, ComboBox and DataGridView objects. |
| Line 16: | Line 21: |
| ---- | We are building a Model View Controller (MVC) application. |
| Line 18: | Line 23: |
| The following data may be out of date... | 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. |
| Line 20: | Line 25: |
| '''FORM CONTAINS:''' | 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. |
| Line 22: | Line 27: |
| * HashMap<FieldRomanNumeral,FieldData{''Field Information'', ''List<SquareData>''}> * HashMap<FieldRomanNumeral|SquareDesignation, SquareData{''Square Information'', ''List<BaseLocusData>''}> |
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. |
| Line 25: | Line 29: |
| Incidentally the ''List<SquareData>'' should match the tabs shown under the squares tab for that Field. Can we map it directly? | == Controller == |
| Line 27: | Line 31: |
| Also, the ''List<BaseLocusData>'' maps the the list of tabs showing the loci - ''even though'' these are not "controls" each BaseLocusData element will contain controls. | 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 that both interact with the Database and generate and control the view of that data. The tab control is acquired and a tab page added with the appropriate labels. Then the controller object provides a ctrlPanel that is placed on the Tab. The control panel 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. The LocusDataX object is added to the controller hierarchy in the squares squareLoci Dictionary. For a general description of how these objects work see the base object from which they inherit much of their functionality: LocusDataBase. |
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:
- SQLExpress is now and for the forseable future what we are using.
EntityFramework or NHibernate (http://nhforge.org/Default.aspx) and possibly Fluent NHibernate (http://fluentnhibernate.org/) for database business objects instead of hand coding the ObjectRelationalMapping.
SpecExpress framework for specifying property rules validation (http://specexpress.codeplex.com/). Quite frankly, the validation is happening now! As in post Alpha stage, we are now implementing this. See how at SpecExpressImplementation
For now we have the Main Form instantiating the Controller Logic, the Controller Logic instantiating the UI as needed and gluing it to the Model. Our implementation blurs the Controller and ORM functions which sit on top of the Dataset object.
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> object that maps the Field Identifier to an object for the specified field. This Dictionary object is the top controller object in the UI 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 to initiate a some control functionality. Basically we bind three types of UI objects (click on each one to see documentation about binding the UI object to business object properties): TextBox, ComboBox and DataGridView objects.
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 that both interact with the Database and generate and control the view of that data. The tab control is acquired and a tab page added with the appropriate labels. Then the controller object provides a ctrlPanel that is placed on the Tab. The control panel 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. The LocusDataX object is added to the controller hierarchy in the squares squareLoci Dictionary.
For a general description of how these objects work see the base object from which they inherit much of their functionality: LocusDataBase.