【问题标题】:What is the good way of using lookup table in business logic?在业务逻辑中使用查找表的好方法是什么?
【发布时间】:2015-11-11 09:27:55
【问题描述】:

我被要求使用表格来存储实体类型的状态。通常我之前总是使用枚举。

存在实体状态变化的业务逻辑。这个逻辑被封装在实体中。当状态是枚举类型时,这很容易。但是现在我需要注入一个服务来获得所需的状态。我不知道将服务(如 StatusService)注入该方法是否是一个好主意,使该方法依赖于 IStatusService。

示例代码:

public class MyEntity
{
    public MyEntityStatus Status { set; get; }

    public void MethodInWhichStatusMayChange(IMyEntityStatusService myEntityStatusService)
    {
        //using myEntityStatusService to get the status when it should change
    }
}

public class MyEntityStatus
{
    public string Name { set; get; }
}

public interface IMyEntityStatusService
{
    MyEntityStatus GetStatusA();
    MyEntityStatus GetStatusB();
    MyEntityStatus GetStatusC();
}

【问题讨论】:

  • MyEntityStatus 类的意义何在?它没有任何方法或抽象。恕我直言,这不是很有用。
  • 重点是在数据库方面工作的人不必看我的枚举值,数据完整性也更好。
  • 代码生成怎么样?只需根据数据库值生成枚举。只要不动态添加状态,这就是一个很好的策略。

标签: c# .net oop domain-driven-design lookup-tables


【解决方案1】:

最好在类构造函数中注入服务:

public class MyEntity
{
    private readonly IMyEntityStatusService myEntityStatusService;

    public MyEntity(IMyEntityStatusService myEntityStatusService)
    {
        this.myEntityStatusService = myEntityStatusService;
    }

    public MyEntityStatus Status { set; get; }

    public void MethodInWhichStatusMayChange()
    {
        //now you use the private myEntityStatusService field
    }
}

如果您决定使用依赖注入引擎,这将使您的生活更轻松,而且您的代码将更干净、更易于使用(您不必传递IMyEntityStatusService 的实例),并且正如所指出的那样在 cmets 中,更容易测试。

【讨论】:

  • 最重要的是——它将是可测试的并且易于执行单元测试:)
  • @RanSasportas 如果你使用方法注入,是什么让它无法测试?
  • @SriramSakthivel 方法注入也是可测试的,但构造函数注入更容易测试,因为它是大多数测试框架开箱即用的模式。
  • @jannagy02 另一种选择是使用“工厂模式”。只有一种方法可以创建使用一些枚举参数化的状态。 CreateStatus(EntityStatusEnumType)
  • @SriramSakthivel 这对我有什么好处吗?在这种情况下,工厂应该依赖于服务。
猜你喜欢
  • 2011-09-07
  • 1970-01-01
  • 2011-03-17
  • 1970-01-01
  • 2011-09-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-05-04
相关资源
最近更新 更多