Objectives:
Techniques to investigate
Keeping separate mapping files will become essential.
- If you want to maintain the HIS Desktop schema as a separate specification, then the HIS Desktop team will have to develop and maintain the mapping.
- We need to work on namespacing the classes, and using "using" statements in the development
Scenario to test
SeriesOdmData get's renamed to:
Odm.Series.
We create Odm.Sites, Odm.Variables. Add the standard fields (state, county, elevation_m, etc (if full 1.1 compatibility is desired, we'll have to hack it up)). There will be methods to store them as properties.
On a branch, you can create an 'Hisd' directory in the model project to store classes for hisdesktop. These would supports methods his desktop needs with methods of the standard Odm (or other base class). Hisd.Series (and other classes) would override the methods of Odm.Series to support storing the fields into database columns (rather than properties as the new model utilizes).
We should investigate if these can be handled by using an additional project, with a specific mapping project for hisdesktop. This might use a table per class mapping, so that HIS desktop schema could be utilized. It might even be possible to not have to map all the classes, and just map the his desktop, and some core classes.
HIS desktop code can be configured to use this
using aSeries = Cuahsi.Model.Hisd.SeriesAnd if you want to use the new rules, you can use this
using aSeries = Cuahsi.Model.Odm.Series Notes
I know the HIS Desktop schema is "set" but review these documents before committing to the HIS DB.
We (USU and SDSC) have always taken a model and created a schema that was simple, because coding against a complex DB schema can be a pain. Using an ORM removes that, and provides an opportunity to start clean, with a domain model, that can be used to create different DB schemas, or even used in different ORM's.
We moving SDSC code towards an object model because I want to talk about the information: the Model and the rules. , We want to not worry about simplifying stuff in order to accomdate the database schema, or the programming against a database schema. I really want a shared model... and I want a clean start... not a legacy start. I want a datamodel that can handle the legacy, and yet, provide a future.
Things for the HIS Desktop team to review:
And before committing to HIS Desktop schema, read the two use cases here:
http://river.sdsc.edu/wiki/ODM%20Use%20Cases.ashx
And remember, this is part of my original concepts of moving towards a series model, and this is really what I am attempting to move towards.
http://river.sdsc.edu/wiki/ODM%20Changes%2020070723.ashx
And best practices that will need to be dealt with if you ever use a data loading tool... We could code them into the model, or classes that talk to the storage layer. Shared code.