Telerik blogs

Benefits of Code-Only Mapping and How to Get Them

by Ivailo Ivanov
May 15, 2015 Productivity 0 Comments


There's no doubt that the Data Access Visual Studio integration has its unique place in the development process of your applications. On one side, the wizards quickly lay the foundations of your data access layers, and after a few clicks you are ready to execute CRUD operations against the database. On the other, the integration gives you a hard time automating the build process, and makes you and your teammates keep in sync the version of Data Access that you work with. In this situation, you discover that the Data Access NuGet packages do not bring the two sides together, and that you have to choose between using the Visual Studio integration and the convenient configuration.

In short, the need to decide arises because, by design, the Data Access NuGet packages work only with code-only mapping. The common sense behind this decision is that the proper support of an .rlinq file requires the presence of a few assemblies in the GAC folder of the machine and the availability of others (Visual Designer specific). These assemblies are not otherwise necessary during the build process or for consuming the models. In other words, it implicitly requires a Data Access installation.

In an effort to find a configuration that combines the .rlinq file and the Data Access NuGet packages, we researched a few middle-ground options. Although we made them work, we found out that it was very difficult to support them. To give you a glimpse of the maintenance cost, following are the activities we performed on a regular basis for an example project under source control:

  • Upgrade of the NuGet packages in the model project when any of the team members upgrades Data Access. Upgrade of Data Access on your development machine, as well.
  • Make sure that the model project refers the Data Access assemblies and Enhancer from the packages folder, and their versions are the same. Edit the .csproj/.vbproj file as text to do this.
  • Make sure projects that consume the model refer to the same version of the Data Access assemblies as those used in the DAL project.

Therefore, we changed the mapping approach of the example model to code-only and installed the Telerik.DataAccess.Fluent package on the project. The benefits we experienced immediately are:

  • Easy upgrades of Data Access.
  • No need to install Data Accesson the build machine.
  • No need to install Data Access in order to make model changes.
  • The model changes that need to be persisted in the database can be handled by the UpdateSchema method.
  • The only modifications introduced in the code and the model are those the developers will do (no unwanted or version related changes in the .rlinq file).
  • There is almost no risk of unbuildable code and runtime errors after an upgrade to a higher version.
  • No changes and checks in the .csproj/.vbproj files.
  • To download the NuGet packages, you can either use the on-line NuGet repository or set up a local one.

It is worth saying that a favorable argument for this decision was that Data Access already has the necessary tools to make such conversion, and there was no need for us to start coding the model from scratch.

Here is how we configured the sample project:

  1. Open the .rlinq file in Visual Designer.

  2. Set the mapping type to Fluent from the Model Settings dialogue and the Code Generation page, and click OK to close the dialogue.

  3. Save the .rlinq file and add a new folder in the project. For example, you can name it MyFluentModel.

  4. Open the project folder in File Explorer and move the persistent classes, the context class and the metadatasource class in the MyFluentModel folder.

  5. In Solution Explorer, delete the .rlinq file from the project and include the moved files in the MyFluentModel folder.

  6. From the Manage NuGet Packages dialogue, install the Telerik.DataAccess.Fluent package on the project.

  7. Save the project.

At this point, you need to review the metadatasource class. If your model contains hierarchical structures, you will experience this error:

Telerik.OpenAccess.Metadata.Fluent.EntityMap.HasDiscriminatorValue(string) is obsolete: This method is marked as obsolete because HasDiscriminatorValue on the MappingConfiguration has to be used.

 

To resolve it, you need to paraphrase the mapping configuration of the affected class. Initially, it will look similar to the following:

configuration.MapType(x => new { }). 
    Inheritance(InheritanceStrategy.Default). 
    HasDiscriminatorValue("MyModelNamespace.MyPersistentClass");

 

You can change it like this: 

configuration.MapType(x => new { }).Inheritance(InheritanceStrategy.Default); 
configuration.HasDiscriminatorValue("MyModelNamespace.MyPersistentClass");

 

You may also want to review the mapping configuration of properties that are mapped to computed columns. In the persistent classes, these properties should be read-only: 

public virtual string Addres 
{ 
    get 
    { 
        return this._addres; 
    } 
}

 

And, they should be mapped as such using DataAccessKind.ReadOnly:

configuration.HasProperty(x => x.Addres).HasFieldName("_addres").
    WithDataAccessKind(DataAccessKind.ReadOnly).ToColumn("Addres"). 
    IsNullable().HasColumnType("varchar").HasLength(255);

 

That's all. You are ready to build the data access layer and to check-in the project under source control.

NuGet, Telerik Data Access
About the Author

Ivailo Ivanov

 is Team Lead in Telerik Data Access

Comments

Comments are disabled in preview mode.