ORM Designer for Entity Framework

Jean-Pierre Bachmann
9y
14.4k
0
3

Article

Introduction

Today, I will describe Devart, an Entity Developer tool from Software Factory. Microsoft announced some weeks ago that they will no longer support designer-driven development using the EDMX Designer. Therefore, I decided to consider some third-party tools.

I will guide you through an example application by creating a small example. The free version of Entity Developer, the Express Edition, will be considered. The only restriction that really "limits" us is the limited number of 10 entities per model.

Background

Why do we even need something like an ORM Designer for entity framework? This is a tough question and of course we don't need it. We need it as much as we need a designer for a Windows Forms Project, but there are also some advantages. One of the most exciting features is that we define our business logic, one within the Entity Developer in there way and then we generate our code from the logic. Entity Developer uses T4 Templates to transform the model to code (that's what they mean by Custom Templates). If you own a version other than the Express one, you can create your own template to generate your code, but there are many predefined templates that will fit most of your needs.

Example

I will create a small application in C# with the Entity Developer to manage some bills for us. After installing the Express version, we will start it and create a new Model. The new model will be called Accounting Model. As we are able to work with multiple database providers we can choose from the following.

LINQ To SQL
NHibernate
Entity Framework

We will choose LINQ To SQL.

Next we need to decide what model creation strategy we want to use. Here we will choose Model First to implementing the above mentioned idea.

Enable automatic synchronization. If it is enabled, we can allow the designer to update our model automatically from the database and return. We can disable it to gain more control over the Creation of the Entities.

In the next screen we can define some basic options, such as the namespace of the generated models. This is typically equal to the project that contains the database access layer. Also helpful is the storage of the connection string inside our App.config file.

Then we come to the code relevant and developer dependent part. With the code generation strategy comes the Developer to its part. The Express version of Entity Developer defines 9 Templates for generating code from your Model. Depending on your selected Model type in the first dialog window, the corresponding template is predefined, in our case it's the "LINQ to SQL". But you can select more templates in addition that will be used to translate you code. You can add them by pushing the Red marked button in the upper left corner.

This will invoke a dialog in which you can select multiple other templates. For example, if you need to support Windows Phone for our LINQ to SQL classes we also need to create models for that case, then we could create them in addition to our "Non" portable classes. Also helpful is the MVC support. It creates Views for ASP.Net by using a Model as the base and can event include Bootstrap for the Form creation. Check out the list of all templates at Devart. For our sample project we will keep the preselected one and continue to the next dialog.

As T4 Templates define several parameters, you got some kind of control over the code generation process. We will define that every Entry in the model should be translated into its own file and that the restrictions (such as Max length) should be validated on the client side by a framework. Also we will define an alternating Output path. That will be necessary since we keep the domain knowledge in the form of this Model Designer away from the code and View.

Then we are done with the setting up of a Model. Now fill it with our business logic.

Model Creation and Business Logic

After the creation of your basic model, we need to include the data structure. For this we will go through the Designer and DataContext. Since we chose the CodeFirst approach, we got no immigration from an existing source. This is still possible; we could just open the connection to a database and pull all the interesting information from it. But for this case we need to do it all from scratch. We will start with a simple table structure to store our bookings. It is simple to add a new table. We will use the Context Menu inside the editor and can navigate to:

Add -> New Class

Or we can use the Shortcut:

Alt + C

Or we can use the direct way to select the DataContext node called Classes and use the Context Menu to add a class. We can also use the Toolbar icon. This is very similar to the well-known Entity Framework designer.

The next procedure is pretty straight forward. We need to define several properties and members of the model we need to create. For our Bookings Table I will create some columns and modify the class.

At this moment this will fit our need perfectly. After we press the OK button, the Bookings Entity will appear in our diagram. In addition, I created an Iban Table and dropped the plain text Iban property from the Bookings table. In the next step we will add a relation.

This can be done by selecting the "Bookings" table and use our Context menu and Menu item Add. While navigating, we will get the agony of choice. What kind of Relationship we want to define? Remember, this is not a strongly-typed SQL table, just models. We could also define some kind of inheritance and let the Translate engine in the end resolve the model. I have just added 2 additional models to the schema that inherits from Bookings.

The PriorityBooking and the FutureBooking are both defined as a single entity for now. To assign them to the Booking entity we will select the Booking entity and use the context menu or press:

Alt + I

But first we should remember some facts. At this point we:

Have not created any line of C# Code
Do not have a database-related structure

Because we decided to create all this from the Tool, nothing yet exists. To see how an inherited class will be translated into the database and C# code we need to define this dependency and then compile it.

Both PriorityBooking and FutureBooking inherit from Bookings, but only the Bookings entity should represent the Table Bookings. This can be done by defining Inheritance. We are using the BookingsTable as the base class and at first the derived class will be FutureBooking and PriorityBooking after that.

Now it's time to compile all this information into our systems. We will first generate our Database from this model. This can be done using the Context Menu inside the Designer and selecting "Generate Database Script from Model" or using the following:

Alt + Ctrl + G

When you follow the opening dialog, you will be receive a TSQL statement that would build your database. In our case (with selecting nothing at the start) we will click on "Next".
Warning: If you want to regenerate the database you need to specify many other options.

-- Script was generated by Devart Entity Developer, Version 5.7.594.0
-- Script date 27.04.2015 17:59:43
-- Target Server: SQL Server
-- Server Version: 2014
--
-- Creating a table dbo.Ibans
--
CREATE TABLE dbo.Ibans (
Iban_ID BIGINT NOT NULL,
Name VARCHAR(8000) NOT NULL,
Comment VARCHAR(8000),
CONSTRAINT PK_Ibans PRIMARY KEY (Iban_ID)
)
GO
--
-- Creating a table dbo.Bookings
--
CREATE TABLE dbo.Bookings (
ID_Booking BIGINT NOT NULL,
Balance DECIMAL NOT NULL,
Antedated DATETIME2 NOT NULL,
IsBookingDone BIT NOT NULL,
Priority INT NOT NULL,
CONSTRAINT PK_Bookings PRIMARY KEY (ID_Booking)
)
GO

As you can see here, it only creates one table called Bookings that is an aggregation of Priority-Future/Bookings. Since there is nothing similar to Inheritance in SQL, the information is aggregated. But now comes the easy part, that is the C# code generation of the Entity. This can be easily triggered using the "Play" button in the Toolbar.

After the Translator run through, we can use the Translated .cs files in any way we would like to. We now have 5 classes. But why? We only defined 2 Tables. Yes that's right, but depending on your strategy you need to do a bit more than just define the classes you need to wrap the access to it and must follow some rules. And then there is our "Special" case. We defined 2 divided types from the Bookings Entity and this logic is built into the C# classes because they actually support Inheritance.

When we look into the Visual Studio Code Map, we can exactly see the hierarchy that was built into our C# classes.

This was a small introduction of the Devart Entity Developer tool. From my point of view this tool will be increasingly important since EF 6 will loose the designer. It works perfectly as a LINQ to SQL designer and will be a proper replacement for the EF designer. With the extended capability and extensibility it's a very good tool.

Tip

Check out the Devart Webpage. There are many other tools and programs for developers and a whole bunch of Visual Studio extensions. Just take a look into the resources at the bottom for downloading.

Resources - Downloads