What is the difference between using dbset and mappers in EF7
I started working with .net core
and Entityframework 7
in Onion Architecture
! I have read this tutorial and I think this is the best example for learning the next topic. but one part of this tutorial made a big question in my brain. like what you see on this linked page; on the data layer we have some classes that are our model !!
public class User : BaseEntity
{
public string UserName { get; set; }
public string Email { get; set; }
public string Password { get; set; }
public virtual UserProfile UserProfile { get; set; }
}
public class UserProfile : BaseEntity
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string Address { get; set; }
public virtual User User { get; set; }
}
and some class that displays over such models !!
public class UserProfileMap
{
public UserProfileMap(EntityTypeBuilder<UserProfile> entityBuilder)
{
entityBuilder.HasKey(t => t.Id);
entityBuilder.Property(t => t.FirstName).IsRequired();
entityBuilder.Property(t => t.LastName).IsRequired();
entityBuilder.Property(t => t.Address);
}
}
public class UserMap
{
public UserMap(EntityTypeBuilder<User> entityBuilder)
{
entityBuilder.HasKey(t => t.Id);
entityBuilder.Property(t => t.Email).IsRequired();
entityBuilder.Property(t => t.Password).IsRequired();
entityBuilder.Property(t => t.Email).IsRequired();
entityBuilder.HasOne(t => t.UserProfile).WithOne(u => u.User).HasForeignKey<UserProfile>(x => x.Id);
}
}
and it uses these mapping classes in the OnModelCreating method DbContext
to create the following models as a table in the database:
public class ApplicationContext : DbContext
{
public ApplicationContext(DbContextOptions<ApplicationContext> options) : base(options)
{
}
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
new UserMap(modelBuilder.Entity<User>());
new UserProfileMap(modelBuilder.Entity<UserProfile>());
}
}
My big question is this: we can use DbSet<>
for each object inside the db context and avoid writing mapper and instantiating in the method OnModelCreating
DbContext
. why didn't this tutorial use dbset ?. why should we create cartographers!
source to share
My big question is, we can use DbSet <> for each object inside the db context and avoid the mapper write and create it in the OnModelCreating method for the dbcontext. why didn't this tutorial use dbset ?. why should we create mappers!
new UserMap(modelBuilder.Entity<User>());
This is basically the EF Core way of setting up and mapping an Entity in a DbSet using the Fluent API.
DbSet <> for each object inside db context and using Mapper to set up DbSet are the same.
In Entity Framework 6 we are using EntityTypeConfiguration and create mapping classes like this . This is a very clean comparison to Data Annotation and follows the Single Responsibility Principle.
Beauty - we just need the following code to automatically set up hundreds of objects using reflection.
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
...
var typesToRegister = Assembly.GetExecutingAssembly().GetTypes()
.Where(type => !string.IsNullOrEmpty(type.Namespace) &&
type.BaseType != null &&
type.BaseType.IsGenericType &&
type.BaseType.GetGenericTypeDefinition() == typeof (EntityTypeConfiguration<>));
foreach (var type in typesToRegister)
{
dynamic configurationInstance = Activator.CreateInstance(type);
modelBuilder.Configurations.Add(configurationInstance);
}
base.OnModelCreating(modelBuilder);
}
Alternatively, we can use the Entity Framework Power Tools and create an Entities and Mapping configuration from an existing database. It only takes a few minutes to generate hundreds of tables into classes. It was a great time-saver for us.
Sorry, EntityTypeConfiguration<T>
not yet available in EF Core . I think many of us still like to use the old approach with the new EntityTypeBuilder<T>
one to keep the Mapping configuration out DbContext
, although it's not as smooth as we did in EF6.
source to share
I'll only cover part of your "big question", probably changing your original guess:
why didn't this tutorial use dbset? why should we create mappers?
You missed a huge point . Check the tutorial again and have a look at this piece of code:
public class Repository<T> : IRepository<T> where T : BaseEntity
{
private readonly ApplicationContext context;
private DbSet<T> entities; <---- HHHEEEERRREEEE
I marked this for you. Yes. The tutorial actually uses DbSet <> . The fact that they push the dbsets into the "repository" is just a convenience and formalism of the onion architecture: they expose the "IRepository" from the layer instead of directly displaying the DbSets - just to keep the EntityFramework reference pending and not allow any other layers that EF is used internally ... But that doesn't mean they don't use DbSets. Obviously the repository uses DbSets.
This is because DbSet and Mappings are completely different things. Mappings define how to map classes / properties to tables / columns, and also add some metadata like which column should be non-null (= properites should be "required"), which / which indexes to create, etc.
But all these mappings give you NO to load / insert / update records. It only defines what databases and classes look like.
DbSet is used here for execution operations . It defines methods that work with data defined by cartographers.
source to share