Entity Developer 6.12 with More Data Types, Template Improvements, and More

The new release of Entity Developer 6.12 mainly focuses on Entity Framework Core support improvements, that are based on the feedback of our users. We will continue to work on these features, and some of them may be also ported for other ORMs in future.

Entity Framework Core 6

Previously, EF Core 6 supported both .NET 5 and .NET 6 in its first preview versions. Previous Entity Developer versions supported EF Core 6, and you could design EF Core 6 models in both Entity Developer integrated to Visual Studio 2019 Preview and in the standalone and console versions.

Currently EF Core 6 has discontinued .NET 5 support, and supports only .NET 6. .NET 6 support has also been removed from Visual Studio 2019 Preview, and is currently available only in Visual Studio 2022. The latter doesn’t have a stable version yet, and has the Preview status. Entity Developer doesn’t yet support integration to Visual Studio 2022, so now it supports EF Core 6 models only in the standalone and console versions.

Support for New Types

We continue extending the list of types, supported in EF Core models. The previous Entity Developer version introduced support for IPAddress and PhysicalAddress types. The new 6.12 version adds Uri to the list of supported types (to the Other Types section). Uri type is supported for EF Core 3, EF Core 5, and EF Core 6 models. EF Core providers that support this type, usually map it to a string data type in a database (varchar, text, etc.).

.NET 6 also introduced new DateOnly and TimeOnly types that can be more suitable in some cases than more universal classical DateTime and TimeSpan types. Some EF Core 6 providers started to support these types, so the new Entity Developer version supports them too. DateOnly and TimeOnly types are now available in the Primitive Types section.

The list of supported types in Entity Developer grew significantly over time, but the corresponding Type UI list in Property Editor dialog box had a small size by default. It has been increased significantly in the new Entity Developer version, making selection of a property type more convenient.

Storing Model Connection

Previously, a model connection string was always stored in one of the model files (in a edps file, specifically). However, in a number of cases this approach is not suitable because of the security considerations. This applies to cases when the model is stored in a code repository (Git/Mercurial/SVN/etc.), and more people have access to this repository than should have access to the connection string.

Preiously, the only security feature, allowing you to limit sensitive security information stored in the model was the Persist Security Info parameter. If set to False, password was removed from the connection string when saving the model. This is not enough in many cases, so the new Entity Developer version offers additional security features.

Now you can discard saving the connection string in model file completely. This offers the highest security, but can be excessive and inconvenient if you need to connect to the database often, for example, to sync model changes with the database or vice versa.

That’s why we have supported storing connection string to Entity Developer storage for EF Core models. The connection string is still linked to the model, but is stored separately, in the Entity Developer settings directory for the current user:

%APPDATA%\Devart\Entity Developer\Storage\

Connection strings are stored in the following files:

%APPDATA%\Devart\Entity Developer\Storage\<model_guid>.xml

As an alternative, you can also store the connection string in an environment variable of the current user. This alternative is suitable in many cases, but not universal. It may not fit for cases with very long connection strings or if the user already has a lot of environment variables.

As for our future plans for this feature, we are considering adding at least partial support of the ASP.NET Core User Secrets feature. This task has its own complications, because this feature is intended only for .NET Core applications and is closely associated with with Visual Studio projects.

Code Generation Template Improvements

Repository and Unit Of Work Template

The Repository and Unit Of Work template has got the new “Generate UnitOfWork Repository Properties” property for EF Core models (by default, True).

Before this property, the generated IUnitOfWork interface had only the Save() method, and obtaining repositories (which could be implemented in multiple ways) had to be implemented by the users.

    public partial interface IUnitOfWork : IDisposable
    {
        void Save();
    }

Now, if you set “Generate UnitOfWork Repository Properties” to True, the IUnitOfWork interface provides access to all repositories:

    public partial interface IUnitOfWork : IDisposable
    {
        IRepository<Emp> Emps { get; }
        IRepository<Dept> Depts { get; }
        void Save();
    }

Data Transfer Object Template

The Data Transfer Object (DTO) template now has the new “Validation Framework” and “Validation Error Messages” properties for all ORMs. The main EF Core template had them before, for generating the DataAnnotation attributes for model classes. Now you can easily generate them for DTO classes as well.

    public partial class DeptDto
    {
        [Key]
        [Required()]
        public int Deptno { get; set; }
 
        [StringLength(14)]
        public string Dname { get; set; }
 
        [StringLength(13)]
        public string Loc { get; set; }
 
        public List<EmpDto> Emps { get; set; }
    }

EF Core Template

One of the unique EF Core model feature is support for enum types, defined in the model, and generating code for them. However, in some cases when using such enums as property types of entities and DTO classes, there may be a problem with DTO template if output is generated to different projects.

For example:

• The EF Core template generates everything to a project A.
• The Data Transfer Objects template generates DTO classes to another project B that doesn’t reference A.
• The Data Transfer Objects template generates DTO converter classes to a project C, which references A and B.

In this case, there is a need to specify output for enums. For example, in the above case, we need to generate enums in a new project D and add references to it in all the above projects. For this purpose, we have added the new “Enum Output” property to the EF Core template, that allows you to specify output for generated enums.

Conclusion

Entity Developer development is heavily based on the feedback of our users. Please do not hesitate to share your use cases and suggestions, and we will try our best to provide a better user experience for you.