Question

我有来自projectant和实体的uml图我有方法getTotalPrice（）

所以这是我的班级：

public class UOrder {

   @OneToMany
   private List<Product> products;

   ....
   public BigDecimal getTotalPrice(){
   BigDecimal b = new BigDecimal(0.0);
   for(Product p : products){
   b.add(p.getPrice());
   }
   return b;

 }

}

这样做是个好主意吗？逻辑业务进入实体？ 我只有uml图中的函数而不是字段totalPrice或类似的东西所以我发现它一定是那样......

Answer 1

这更像是品味问题。例如，如果你喜欢Domain Driven Design哲学，这是一个非常好的主意，因为总价格属于UOrder类。

Answer 2

我认为还不错，但我更喜欢（伪代码）：

public class UOrder {
    ...
    public BigDecimal getTotalPrice() {
        return PriceUtil.getTotalPrice(products);
    }
}

public class PriceUtil {
    public static BigDecimal getTotalPrice(List<Product> products) {
        return sum-of-products;
    }
    ... other userful and fancy price functions ...
}

因为你通常需要：

计算增值税或
其他类别的产品价格或
其他类别的价格为UOrder
等等。

Answer 3

作为一种替代观点（一个活跃的记录样式数据映射对象只是一个方便形式的持久数据 - 一个值对象），这就是我的想法：

鉴于您已经说过方法是业务逻辑，并且给出了@Anton谈论的众所周知的域 - 这是一个坏主意。如果你没有说它是业务逻辑，我会质疑你为什么在你的应用程序中关心这个总数。

作为一项实验，请考虑重新命名映射的类UOrderData，将其视为值对象，并使用UOrder类在应用程序级实现业务逻辑。

EJB，JPA业务方法转化为实体

3 个答案: