Closed trungcaot closed 4 years ago
I also do not like application layer to reference EF Core. Maybe IDbContext interface should expose IQuaryable instead of DbSet?
Agree, we should avoid DbSet in IApplicationDbContext
I have also updated the code for this case by implementing a generic repository and unit of work to remove ef core in the application layer. You can refer to an example project MsCoreOne with link to look at it. Hope everyone likes it and gives me some feedback. Thanks.
I have also updated the code for this case by implementing a generic repository and unit of work to remove ef core in the application layer. You can refer to an example project MsCoreOne with link to look at it. Hope everyone likes it and gives me some feedback. Thanks.
That's what I had in mind to do. But how would you do custom queries? In the repository and put the DTO's in the Application?
Hi @carloswbarros,
Thanks for your comment!
@trungcaot
Can I do a custom select in "ProductRepository.cs" for example, that returns a "ExampleProductDTO"? Ex (ofcourse this is a simple query, but can bem more complex with joins, etc):
public List<ExampleProductDTO> GetExampleProducts()
{
var products = _context.Set<Product>()
.Select(p => new ExampleProductDTO(p.Id, p.Name))
.ToList();
return products;
}
If your answer is 'yes', than where should I put the "MyCustomProductDTO" file? Should I put it in the Application layer?
Should I call "GetExampleProducts" in a "QueryHandler"? Won't that get too repetitive? Maybe I'm just overthinking it..
Thanks
@carloswbarros
Thanks.
@trungcaot Thanks for the answer!
So if you want to create a query you need to do something like this:
I like it, my only problem is having to map 2 times just for a query.
@carloswbarros
In my point of view, current you probably see mapping 2 times but it will have a benefit in the following case.
Define a function and return ProductQueryResult in ProductRepositry
You can use these function to many handlers
if we return a specific DTO for this function, we will probably define 2 functions. So I prefer we should separate DTO with class mapping to the domain. It's clearer and we can reuse this function in many handlers.
Thanks.
@trungcaot Ye it makes sense. I like this idea
@trungcaot @carloswbarros While this is a viable option to remove the EF Core dependency, I think this ends up adding too much boilerplate code to be worth it in a bigger real-world project.
Imagine working in a solution with over a hundred different Repository concrete and interface classes. The solution just becomes more and more bloated with very similar code and becomes more difficult for new developers to get in and understand the codebase. Also, doing this will add significant complexity due to the scenarios mentioned above that don't currently exist.
For those reasons, I'd like to see EF Core remain the Application layer of this template. If you see your specific project needing to divert from EF Core, then the pattern you've outlined should work.
I thought that if we install ef core in the application layer then it will make this layer depend on ef core once we probably change ORM to Dapper or something like that, we must update the code of the application layer.
Should we do handle it on the infrastructure layer as the best practice on onion architecture?
Pls look at my idea and give me your idea on this question. Thanks