Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

The immediate problem I see here that it becomes hard to unit test the "UnitOfWork" with mock repositories. What if the line repoItem = new Repository<TEntity, object>(Context); needs to be replaced by ... new MockRepository for a meaningful test? So in case UnitOfWork just needs one or two, maybe 3 repos, you could try to inject them in the ...


You mention "EF auto generated classes", which suggest you're using a DB-first approach. But you mentioned in the comments that you're open to anything, so I want to suggest switching to a Code First approach. Robert Harvey's answer isn't wrong, I simply want to offer another viable solution to the problem. Note: I don't know much about EF Core ...


Just use the EF auto-generated classes in your domain models. For example: public class Invoice { public int InvoiceID { get; set; } public Address BillingAddress { get; set; } public Address ShippingAddress { get; set; } public List<InvoiceItem> LineItems { get; set; } } Where Address and InvoiceItem are both auto-generated EF ...


You're missing the singular nature of the unit of work. Effectively, what you want is a context that is used in more than one action: The long running process Any additional request to view the object status while the long running process is still running Based on your code, you are expecting for the second web request to effectively look into the existing ...


Work with application events and/or a message queue. Your current approach inevitably leads to polling. You achieve much greater scalability and user experience with an event-based approach.

Only top voted, non community-wiki answers of a minimum length are eligible