对于每种数据库查询，我都应该有新的实体吗？

Question

是否有最佳方法来避免大量的DTO和实体？

现在，我的应用程序对每个数据库表都有一些实体和DTO。 但是，由于来自用户界面的查询变化很大，因此我为每个查询创建了新的实体和DTO，这导致DTO-Entity陷入困境。

举个例子：

尽管我们的应用程序非常简单，并且只有两个数据库表：

• 具有ID，名称，年龄，车辆ID的人员表；
• 车辆表，ID，品牌名称，速度，价格；

起点是我们只有以下几类：

• PersonEntity，PersonDto，VehicleEntity，VehicleDto

用户可以通过id和名称获取Persons，Vehicles。 到目前为止很简单。

但是我们有了一个新的要求：

用户想通过人名查询平均车辆价格。 （即所有Franks拥有的车辆的平均零售价为25.213 $）因此，在ui方面，我们需要一个对象： PersonGrouppedAvgPrice，其中包含personName和averagePrice字段

我发现以下解决方案：

1. 因此，要么我们从数据库中获取所有具有给定名称的Person和相应的汽车，然后将其返回到UI（并且计算将在ui端进行），这将导致不必要的网络流量和内存消耗，但是至少我们没有被迫创建新实体。

2. 我们仍然从数据库中获取上述所有内容，并在DTO级别的服务器端进行计算。 在这种情况下，我们仍然没有被迫创建新的实体，但是我们必须创建新的DTO。 网络流量降低，但内存仍然很高。

3. 我们使用以下查询在DAO级别上做出相应的逻辑：
   从person_table中选择p.name，avg（v.price）作为p内部联接...等。在这种情况下，我们只获取最有效的必要信息，但在这种情况下，我们需要新的DTO和实体。

我已经用了第三个。 但是由于各种UI查询，新类的数量升级到了将来无法维护的水平。 对于20个数据库表，我不得不创建〜4-4 Entity和DTO，这是〜160类。

有什么更好的方法吗？

Answer 1

第3点是RDMBS的正确方法。 您应该使用查询在数据库中执行此工作，因为将所有表数据从数据库服务器传输到应用程序服务器效率不高。

对于每个需要特殊投影的自定义查询，您可能最终会得到其他DTO类。 这不一定是错误的，它将有助于编写单元测试。 减少DTO类数量的方法很少，例如，通过使用本文所述的元组。