Applying EF core in Universal Windows Apps using a large database

Question

I am building my UWP app and really stuck in the architecture. For the past few days, I have been reading MVVM, Entity Framework, SQLite, Code First, etc and I am confused how I will implement everything.

In this tutorial, it shows the usage of a dbcontext derived class inside a function called Page_Loaded in MainPage.xaml.cs. Is this a bad design?

I made my own implementation below because I don't want to expose SQL queries on my view XAML files. I am completely unsure if this is better or if I can still improve it or replace it with a better one?

MyDbContext.cs

public class MyDbContext : DbContext
{
 internal DbSet<Person> People { get; set; }
 protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
 {
 optionsBuilder.UseSqlite("Filename=mydbcontext.db");
 }
 protected override void OnModelCreating(ModelBuilder modelBuilder)
 {
 modelBuilder.Entity<Person>().Property(p => p.Id).IsRequired();
 modelBuilder.Entity<Person>().Property(p => p.Name).IsRequired();
 }
}

Repository.cs

public class Repository
{
 public List<Person> People()
 {
 using (var db = new MyDbContext())
 {
 return db.People.ToList();
 }
 }
 public Person GetPersonByName(string name)
 {
 using (var db = new MyDbContext())
 {
 Person person = (from p in db.People
 where p.Name == name
 select p).FirstOrDefault();
 return person;
 }
 }
}

MainPage.xaml.cs

private void Page_Loaded(object sender, RoutedEventArgs e)
{
 entriesListView.ItemsSource = _repo.People();
}

Another thing: if I add many tables, my Repository.cs will grow so large that it might reach thousands of lines, how do you break this one? I might add 30 more tables inside so I could imagine how it will look cluttered inside Repository.cs file.

Answer 1

In this tutorial, it shows the usage of a dbcontext derived class inside a function called Page_Loaded in MainPage.xaml.cs. Is this a bad design?

Yes, I think it is a bad design and implementing a repository the way you did it is the right approach.

---

Another thing: if I add many tables, my Repository.cs will grow so large that it might reach thousands of lines, how do you break this one? I might add 30 more tables inside so I could imagine how it will look cluttered inside Repository.cs file.

Let's talk about it later when you have that many tables but for now in order to avoid a file with thousands of lines (which is highly unlikely) you should already start with different repositories. Now you have only the Respository which is not that bad by itself but it can be better. In your case it should be a PersonRepository. So now you have one for people. When you add more tables later I'm pretty sure you can come up with another repository for them. It doesn't have to always be one repo for a table. You have have repositories that are all about people and work internally with mutliple person-related tables. Then there might be repositories that work with other data like files etc.

Just don't put all your code in a single file. Group the talbles together by what makes more sense.

• Gibs: On point! this is exactly what I wanted to know. Cheers.