The sample is as below:
Table Name:T_BS_AAA_BC
Column Name:BIRTH_DATE
The expected class name：AaaBc (Your tool can implement it)
The expected property name：BirthDate(Your tool can implement it)
The expected field name: _birthDate(Your tool can not implement it)
Also, I don't find a way to set it in a configuration file, for most scenario, project's naming convention is fixed and no need to configure it while creating Entity class in every time. If I have 20 developers in project, how can I ensure my developer use the same naming convention in OpenAccess ORM?
5 Answers, 1 is accepted
Indeed the current version of OpenAccess does not apply some combinations of the custom name settings correctly. We are working on that problem and it will be fixed in the Q3 release.
As far as I understand the second part of your post, you want the definition of all domain entities to be generated with a single naming convention, regardless of when you add them to the domain model and how. If that is the case, can you please send me the following details:
1. Are you creating a new domain model or you are using an existing one?
2. If you are creating a new one which scenario are you going to implement – Model First or Database First?
3. If you are using an existing one, how was it created (Model First scenario or Database First)?
4. How do you intend to add the new classes – by updating from the database or by developing the conceptual model and transferring the changes to the database?
Feel free to share any other details you think might be important.
All the best,
Doroteya
the Telerik team
Rank 1
You can see my following answer:
1.Both
2.Database First
3.Database First
4.By updating from the database
Thank you for the quick response. According to the information you provided I developed two cases. Since they are not alternatives to one another you can use them both depending on the current situation you are in.
The first case I will review is for the following scenario:
You already have a domain model with classes in it. All of these classes are imported to the model from the database but they use different naming conventions. Your goals are:
1) To make the existing classes share a single convention
2) The next classes you import from the database to use the same convention
Solution:
1) Open Visual Designer
2) Right-click on its surface and select Show Model Settings…
3) In the Model Names tab configure the desired naming convention
4) Click OK to save the changes and to return to Visual Designer
5) Select each class in the diagram and delete it from there (Note: that will neither delete the table from the model nor the associations and the constraints related to it)
6) Open the Model Schema Explorer and drag-and-drop each table back on the surface of Visual Designer. At this point you will see that the new naming convention is applied
7) Save the .rlinq file and open the .cs files in the Solution Explorer. You will see that the changes are applied for the generated code too
With that the first goal is achieved and if you do not change the naming settings of the model the same convention will be applied to all the other tables you add from the database.
Note: If, for example, you right-click on the surface of Visual Designer and select Add > Add new domain class, the naming convention will not be applied immediately (because that class will not be a part of your domain model jet). That requires a couple of additional steps.
The second case follows this scenario:
You have an empty domain model (Visual Designer displays no diagram and there are no tables, views, stored procedures and constraints in the Model Schema Explorer). You want to import classes from the database and the goal is all the classes you add from there to share a single predefined naming convention no matter when you add them.
Solution:
1) Open Visual Designer
2) Right-click on its surface and select Show Model Settings…
3) In the Model Names tab configure the desired naming convention
4) Click OK to save the changes and to return to Visual Designer
5) Right-click on the surface of Visual Designer and select Update From Database…
6) Setup a connection, select the necessary tables, preview the changes and click Finish.
7) Save the .rlinq file so that the code for the classes is generated.
Note: Just as in the previous scenario, if you want to use the forward mapping approach, additional steps will be needed to apply the naming settings.
Let me know if you need any further assistance on the scenarios.
All the best,
the Telerik team
Rank 1
Thanks for your good response and solution. In fact, your solution can meet the requirement. But it's still not convenient. Let me see a sample:my project have union naming conversion in DB and have another naming conversion in Entity class. If the db schema want to have a good mapping with entity class, we need to update your naming rule in domain model wizard. In your above two cases, it only convert the batch conversion. From project's point, developer will not to convert the naming after created all entity classes. As developer, developing application is case by case. They will not create all entity class of all case first and convert it again. Maybe developer create one entity class in today, then convert the naming and create another entity and convert it again in tomorrow. My concern is how to ensure developer have one union naming rule while create entity class in every time.
I see your point and currently OpenAccess keeps the naming settings of the domain classes in the .rlinq file itself. So all developers working on the same rlinq will be using the same naming settings for all newly added classes. Also if, for example, you have to change the domain model and you delete the current one you will loose the convention as well.
Actually, the idea about making OpenAccess capable of supporting a single custom naming convention for multiple .rlinq files is in our backlog. In the meantime, however, you will have to set up naming rules for each new .rlinq file.
Do not hesitate to get back to us if you have more questions.
Regards,
Doroteya
the Telerik team