This question is locked. New answers and comments are not allowed.
Gilles Muys
Top achievements
Rank 1
Rank 1
Gilles Muys
asked on 22 Nov 2008, 06:55 PM
OpenAccess seems to use the private field names from the objects instead of the public property names. This does not make sense to me first because private scope information should not be exposed outside of the class, and second, the prefix we use for private field name in the objects make their way to the database. For example, one convention in C# is to use the underscore character as the prefix for private field names; OpenAccess creates database column names that include the prefix. Another worse example: if you declare your properties like this:
public string Name { get; set; }
the database column name ends up being the private field name generated internally by the compiler. Ugly!
How can OPenAccess be configured to avoid this situation and use the name of public properties to generate the database schema? I know that I can use forward mapping and modify the information, but when you deal with hundreds of persistent objects and thousands of persistent properties, this is not a practical solution.
public string Name { get; set; }
the database column name ends up being the private field name generated internally by the compiler. Ugly!
How can OPenAccess be configured to avoid this situation and use the name of public properties to generate the database schema? I know that I can use forward mapping and modify the information, but when you deal with hundreds of persistent objects and thousands of persistent properties, this is not a practical solution.
4 Answers, 1 is accepted
0
Hello Gilles Muys,
We will support automatic properties soon. But OpenAccess is persisting fields, not properties. This is a decision that we did because we think that the properties should be yours and we should not rely on any code inside a property. You can add whatever you want in the properties.
We are just in the planning phase for enhancing the mapping dialogs. What about some grids where you can do the mass operations for all classes or fields in one or more Grids?
Greetings,
Jan Blessenohl
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
We will support automatic properties soon. But OpenAccess is persisting fields, not properties. This is a decision that we did because we think that the properties should be yours and we should not rely on any code inside a property. You can add whatever you want in the properties.
We are just in the planning phase for enhancing the mapping dialogs. What about some grids where you can do the mass operations for all classes or fields in one or more Grids?
Greetings,
Jan Blessenohl
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
Alfred Ortega
Top achievements
Rank 2
Rank 2
answered on 24 Nov 2008, 12:18 PM
I agree with Gilles about the mapping names issue - and the properties issue but using Linq takes care of that for me. For the mapper how about something like the one from IdeaBlade or Opf3. Personally I like to Opf3 one better, but it's not a VS plug-in - it's stand alone.
Here are some ideas:
1) List of Tables/Views (sprocs?) to map and their class name + language to generate to C# or VB. [Tab 1]
Then when you select a table (or view) tabs 2 & 3 are available
2) List of columns to map to columns and their Property name/datatype/is requiried/is db key etc... [Tab 2]
3) Advanced options such as : concurrency/version column, relationships between objects, base classes [Tab 3]
-Al
Here are some ideas:
1) List of Tables/Views (sprocs?) to map and their class name + language to generate to C# or VB. [Tab 1]
Then when you select a table (or view) tabs 2 & 3 are available
2) List of columns to map to columns and their Property name/datatype/is requiried/is db key etc... [Tab 2]
3) Advanced options such as : concurrency/version column, relationships between objects, base classes [Tab 3]
-Al
0
Hello Alfred Ortega,
Sounds good to me, I would like to have not some many tabs, maybe our design team come up with a more condensed view.
To select a different language will not make sense because the language is already defined by the project type.
Thanks for your input,
Jan Blessenohl
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
Sounds good to me, I would like to have not some many tabs, maybe our design team come up with a more condensed view.
To select a different language will not make sense because the language is already defined by the project type.
Thanks for your input,
Jan Blessenohl
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
Alfred Ortega
Top achievements
Rank 2
Rank 2
answered on 24 Nov 2008, 02:07 PM
Jan,
Good point on the languages! Thanks and tabs are of course not needed - just as long as it's intuitive.
Al
Good point on the languages! Thanks and tabs are of course not needed - just as long as it's intuitive.
Al