【问题标题】:EJB, JPA business method into entityEJB、JPA业务方法转化为实体
【发布时间】:2012-09-13 07:15:54
【问题描述】:

我已经从投影中得到了 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 或类似的东西,所以我发现它一定是这样的......

【问题讨论】:

    标签: java jakarta-ee jpa entity


    【解决方案1】:

    我觉得还不错,但我更喜欢喜欢(伪代码):

    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 其他类别的价格
    • 等等。

    【讨论】:

      【解决方案2】:

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

      【讨论】:

        【解决方案3】:

        作为另一种观点(活动记录样式数据映射对象只是一种方便形式的持久数据 - 一个值对象),这是我的想法:

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

        作为一个实验,考虑重新命名您的映射类 UOrderData,将其视为一个值对象,并拥有一个在应用程序级别实现业务逻辑的 UOrder 类。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2011-08-06
          • 2016-02-11
          • 2018-11-09
          • 1970-01-01
          • 2021-02-14
          • 2011-02-15
          • 2011-08-27
          • 1970-01-01
          相关资源
          最近更新 更多