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:
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:
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:
Set the mapping type to Fluent from the Model Settings dialogue and the Code Generation page, and click OK to close the dialogue.
Save the .rlinq file and add a new folder in the project. For example, you can name it MyFluentModel.
Open the project folder in File Explorer and move the persistent classes, the context class and the metadatasource class in the MyFluentModel folder.
In Solution Explorer, delete the .rlinq file from the project and include the moved files in the MyFluentModel folder.
From the Manage NuGet Packages dialogue, install the Telerik.DataAccess.Fluent package on 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.