Resolved How to Implement DbSet and DbContext in Service-Repository Architecture?

[Mitchelln11]

I am updating my .NET Core web app from just MVC to a Service-Repository pattern.

My question is, how do you implement DbSet<> when you add the Service and Repository layers?
I originally added these to my ApplicationDbContext file under the Data folder. Is this still correct? Then would I just use DI to call my database on each repository?

private readonly ApplicationDbContext _context;

public ParkController(ApplicationDbContext context)
{
  _context = context;
}

Or do I have my own DbContext for each table? (Where would DbSet<> go then?)

private readonly ParkDbContext _parkContext;

public ParkController(ParkDbContext parkContext)
{
  _parkContext= parkContext;
}

If I am completely off-base here, or talking nonsense, please let me know.
Thanks!

 

[jmcilhinney]

We used to use services and repositories in my office. We still use services but decided that, when using EF, the repositories added no value. Your EF context basically is a repository layer.

 

[Mitchelln11]

We used to use services and repositories in my office. We still use services but decided that, when using EF, the repositories added no value. Your EF context basically is a repository layer.

That makes sense.
So you still have 1 service layer for each model, right?
Then an additional service layer for models that share values from multiple models?

Thank you so much!

 

[jmcilhinney]

So you still have 1 service layer for each model, right?

Yes.

Then an additional service layer for models that share values from multiple models?

We would generally use hierarchical models so any combined data would still come from the service for the top-level model and have other single entities or collections of entities hanging off it. For instance, you might have a ParentService and a ChildService. The former may have a method to get just a Parent object and another to get a Parent with related children while the latter may have a method to get just a Child object and another to get a Child with the related parent.

 

[Skydiver]

Out of curiosity, with a Service-Repository pattern and a hierarchical models, how do you keep data consistency? Is there an internal version or time stamp that the services pass along to each other so that the returned "view" of the object model is consistent?

Here is a contrived example: I have an Invoice that has: Customer, Invoice Total, and Invoice Line Items. The Invoice itself is the parent object, and the Customer and the Invoice Line Items are the children. So I I ask the InvoiceService for an Invoice by ID, and I get back the Invoice Total, the Customer, and the Line Items. I present that to the user in the GUI the Customer's Name, the line item summaries, and the total. So no problem there yet. The user decides to drill down to a line item to get more details, so there is a request on the LineItemService. While the user is looking at the line item details, the Customer's Name is changed by the marketing department when the customer informs them they have gotten married and changed their name. When the user is done looking at the line item detail and they want to pop back up, there will be a request for the LineItem.Parent on the InvoiceService. Will the InvoiceService return an Invoice object that has an older version of the Customer, or will it return an Invoice with a new Customer?

 

[jmcilhinney]

We do almost exclusively web development these days so we're almost always going back to the database for the latest data. In a Windows app, I would expect that your scenario would display the old Customer data because it is cached in the context. Unless you refreshed the context from the database, which you could do, you're going to see whatever data you retrieved the first time.