Migrating ASP.NET MVC website to ASP .NET Core

I maintain an ASP.NET MVC website that I have been meaning to move to ASP.NET Core, but found the .Net Core 1.1 library rather limited. With the release of .NET Core 2.0 and ASP.NET Core 2.0, we decided to migrate the websites to the new framework. The site has been operational since October 2010 and was built using ASP.NET MVC 2.0. It has gone through various bouts of upgrades and is currently using ASP.NET MVC 5.2.0, which forms the baseline of this conversion. I had several discoveries along the way so thought to blog about them. 

In this post, I am going to write about prep and moving our "Model" to Entity Framework .Core 2.0. 

Background

The model of our website was built using Entity Framework code first. All database operations were performed using repository pattern. Our repository interface looks as follows

    public interface IRepository : IDisposable where TEntity : class

    {

        IQueryable GetQuery();

        IEnumerable GetAll();

        IEnumerable Find(Expression> predicate);

        TEntity Single(Expression> predicate);

        TEntity First(Expression> predicate);

        void Add(TEntity entity);

        void Delete(TEntity entity);

        void Attach(TEntity entity);

        void SaveChanges();

        DbContext DataContext { get; }

    }

We use interface inheritance to create repository for each of our model objects, so for a object "Token", the repository looks like following

    public interface ITokenRepository : IRepository

    {

    }

With the interface inheritance in place. our single generic repository class can the logic for database operations as shown below

public class Repository : IRepository where TEntity : class

    {

        private DbContext _context;

        private IDbSet _dbSet;

        private static string _connectionString = string.Empty;

        public Repository(IDataContextFactory dbContextFactory)

        {

            if (string.IsNullOrWhiteSpace(dbContextFactory.ConnectionString))

            {

                _context = dbContextFactory.Create(ConnectionString);

            }

            else

            {

                _context = dbContextFactory.Create();

            }

            

            _dbSet = _context.Set();

        }

        public Repository(DbContext context)

        {

            _context = context;

            _dbSet = _context.Set();

        }

        public DbContext DataContext

        {

            get

            {

                return _context;

            }

        }

        public IQueryable GetQuery()

        {

            return _dbSet;

        }

        public IEnumerable GetAll()

        {

            return GetQuery().AsEnumerable();

        }

        public IEnumerable Find(Expression> predicate)

        {

            return _dbSet.Where(predicate);

        }

        public TEntity Single(Expression> predicate)

        {

            return _dbSet.SingleOrDefault(predicate);

        }

        public TEntity First(Expression> predicate)

        {

            return _dbSet.FirstOrDefault(predicate);

        }

        public void Delete(TEntity entity)

        {

            if (entity == null)

            {

                throw new ArgumentNullException("entity");

            }

            _dbSet.Remove(entity);

        }

        public void Add(TEntity entity)

        {

            if (entity == null)

            {

                throw new ArgumentNullException("entity");

            }

            _dbSet.Add(entity);

        }

        public void Attach(TEntity entity)

        {

            _dbSet.Attach(entity);

        }

        public void SaveChanges()

        {

            _context.SaveChanges();

        }

        public void Dispose()

        {

            Dispose(true);

            GC.SuppressFinalize(this);

        }

        protected virtual void Dispose(bool disposing)

        {

            if (disposing)

            {

                if (_context != null)

                {

                    _context.Dispose();

                    _context = null;

                }

            }

        }

        public static string ConnectionString 

        {

            get

            {

                if (string.IsNullOrWhiteSpace(_connectionString))

                {

                    _connectionString = ConfigurationManager.ConnectionStrings["Rewards"].ConnectionString;

                }

                return _connectionString;

            }

        }

    }

The class above does all the heavy lifting for us. We just need to define classes that implement each of our models' repository interface. For our model Token, it would be

public class TokenRepository : Repository , ITokenRepository

    {

        public TokenRepository(IDataContextFactory dbContextFactory)

            : base(dbContextFactory)

        {   

        }

        public TokenRepository(DbContext dataContext) 

            : base(dataContext)

        {

        }

    }

Entity Framework Core 2.0 limitations

1. No Many-To-Many Relationship

The biggest issue we have encountered while migrating to .Net Core 2.0 is lack of resolution for Many-To-Many relationships. This is an open issue, which haven't been resolved yet. For us, it means a lot of re-work.

With the POCO way of working, you would start with writing your domain model and your write your business logic using models, without really thinking about relational database details. We have a lot of code where our LINQ queries were based on domain model relationships. Now, we need to re-work all those. 

This, in my mind, is a major issue and though ways to resolve this issue, it prevents Entity Framework .Core from being a true ORM tool. 

As an example, consider you have two entities Parent and Student in your model, where a student can have multiple parents and a parent can have multiple students. With Entity Framework 6, the model definition was sufficient to imply the correct type of relationship. If you have to do it explicitly, you could do it at the time of model creation like below

modelBuilder.Entity()

              .HasMany(p => p.Parents)

              .WithMany(r => r.Students)

              .Map(m =>

              {

                  m.ToTable("ParentStudents");

                  m.MapLeftKey("Student_ID");

                  m.MapRightKey("Parent_ID");

              });

You can then go on and work with defining a collection of Parents in Students class and a collection of Students in Parent class. The .WithMany() method  is not there in Entity Framework Core.

The lack of Many-To-Many feature in EF Core is hard to justify. POCO came out as a good model for domain driven development and not supporting many-to-many in a domain driven world is hard to justify. We didn't want to "dilute" the model with resolving entities, so we decided to "implement" the many-to-many resolution in our code. This series of post describes a good way of keeping domain relationship in our objects, so that there is no change in business logic in other parts of the application.


2. IDbSet Interface 

The IDbSet interface was removed in Entity Framework 6.0, because the team were looking to add new operations to it without defining a new set of interfaces. This is pretty well documented in EF 6.0 design decisions. I do not agree to this decision as it breaks the whole promise of interface as immutable being. The EF team wanted to avoid creating interfaces like IDBSet2, etc for more functions they decided to do away with it. However, the interface is still present in the in EntifyFramework 6.0 library, so our code still worked. Now we had to replace any use of IDbSet with the DBSet class. Also, meant our test code had to be re-written as we mocked IDbSet to for results from database.


3. No Lazy Loading

The entity framework does not support lazy loading as of yet. There is an open issue for it on github.  The feature request is in the backlog of EF team but there is no date of adding it yet. Lazy loading is the default behaviour of Entity Framework and would be there for you if you have the navigation property defined as virtual. This is another big way in which Entity Framework core breaks backward compatibility. 

The way around is to "Eager Loading" i.e. ensure that you use the .Include("") and .ThenInclude("") method in all places, where you are relying on Lazy loading. This is no simple as it's easy to miss it out at placed and the error is only manifested at run time. One way of go about doing it, is to find references of all virtual properties and add .Include("") where the object is "hydrated".


4. No GroupBy Translation

Entity Framework Core 2.0 doesn't support translate Group By to SQL. So, if your application is using GroupBy() method, you might need to take a look for alternatives. Fortunately, more support for Group By is getting added in EF Core 2.1.

The only way to resolve this issue without punitive performance impact is to move the logic to stored procedures. We were using GroupBy mostly in our reports, which were already a candidate to use stored procedures. So, although there was some work involved but the result was much better performance.


Final Words...

My experiences with migrating code from Entity Framework 6.0 to Entity Framework Core 2.0 would not have uncovered all pertaining issues in migration process but this post might help out someone who is looking to take the plunge. 

In my view, Entity Framework Core 2.0 is still a bit under cooked but if you are willing to take do the extra effort, it has enough functionality for you to move your model / data libraries to it.