The OpenAccess Visual Designer is implemented to optimize your data access efforts by helping you create and manage your Domain Model. It is fully capable of handling a database containing several hundreds of tables or designing a complex model of many classes. However it is not doing it as fast as it can with smaller ones. As we believe that ease of implementation is essential for all OpenAccess users, I will show you how you can save even more time with the features packed in the recently released Q1 2013 version.
There are two issues you might encounter when working with large models or database schemas. From one side, the complexity of associating and maintaining hundreds of classes raises with their number. On the other, the T4 code generation that is triggered when the model is saved also requires a technological time to create or replace thousands of lines of code. We acknowledge those drawbacks and we would recommend two different ways of dealing with them, based on your preferences and scenario.
Option 1: Multi-Diagrams
When we manage complexity the first thing that comes to our mind is splitting the model into several parts based on a preselected criteria. This is what the new Multi-Diagrams feature can do for you - it easily creates different views of your model allowing you to easily locate sections and logically connected groups of classes. As a start we have added a new feature to the Add New Item wizard and the Update from Database wizard - create a separate diagram for each database schema:
Whether you choose this option or not, you are provided with a bunch of tools to help you manage the model and the multiple diagrams afterwards, such as:
- Moving classes to a diagrams using drag and drop;
- Copying all the related classes of a particular class to a diagrams (Include Related);
- Copying all the parent and child classes of a particular class to a diagram (Include Hierarchy);
And finally, you can see the new Diagrams node in the Model Objects Explorer where you get an overview of all diagrams and you can control which of them is shown by default when the .rlinq file opened.
This new feature really changes the way you build your large models and helps resolving the first issue we have mentioned - managing the model complexity. Stay tuned and you will see how to tackle the other challenge - firing the T4 code generation for a large number of classes!