Base solution for your next web application
Open Closed

What's the best practice of... #9329


User avatar
0
murat.yuceer created

Hi There,

I'm writing Select queries (not insert, update or delete) for some reports. These queries are creating by joining maybe 6-7 tables. And i'm creating repositories on EntityFrameworkCore layer for these kind of queries.

Then, I have to return my DTO for these kind of select queries. I was just wondering, should I define these kind of DTOs on the Core.Shared layer?

If so, do I need to redefine the same DTO on the Application.Shared layer, to convert it to api? (Because, there is no related reference on that layer. -it doesn't have to be by the way, of course. )

What is the best practice for these type of situations?

And also, i add all my select queries to the repository folder on the EntityFrameworkCore layer. Let's say, there is a entity that named Person. I create PersonRepository on EntityFrameworkCore layer and defined it's interface on the core layer. Do you think that there is a mistake on this?

In general, can you explain the best practice method that you will propose for such complex queries with an example, if possible?


5 Answer(s)
  • User Avatar
    0
    ashgadala created

    We handled all of the complicated queries using the Store procedures and used repositeries to access data. Doing, we were able to take care of performance & Memory issues as well.

  • User Avatar
    0
    ismcagdas created
    Support Team

    Hi @murat.yuceer

    Never define DTOs in the core layer because they are related to Application layer. So, you should define your DTOs in Application.Shared layer. Creating a repository for such complex queries is a good approach.

    And also, i add all my select queries to the repository folder on the EntityFrameworkCore layer. Let's say, there is a entity that named Person. I create PersonRepository on EntityFrameworkCore layer and defined it's interface on the core layer. Do you think that there is a mistake on this?

    This is also a good practice. Repository interfaces should be placed in the Core layer, so you can replace their implementation in case you change the DB provider or even EF Core.

    So, your approach seems good except defining DTOs in the Core Shared layer.

  • User Avatar
    0
    BobIngham created

    @ismcagdas, I have DTO's defined in Core.Shared to support SignalR implementation in Web.Core. Thus, when I want to send an alert to all online devices I need access to a DeviceAlertInput object but I also need access to they same DTO in my Application project to fire the alert from the angular project in the first place. Surely there are some instances when DTO's need to be placed in the Core.Shared when they are shared between Application and Web.Core?

  • User Avatar
    0
    ismcagdas created
    Support Team

    @bobingham

    I wouldn't break the rule of not using DTOs in Core layer fur such a code sharing. You can simply define same class twice.

  • User Avatar
    1
    BobIngham created

    @ismcagdas, interesting. I will take your advice and refactor.