2

我有一个名为 List 的控制器 POST 操作，它接受一个状态变量，该变量可以是以下值 {“all”、“active”、“inactive}。然后我根据“status”内部的值进行存储库调用控制器。控制器看起来像这样：

    [HttpPost]
    public ActionResult List(string status)
    {
        return View(GetJobTitlesByStatus(status));
    }

    private IList<JobTitle> GetJobTitlesByStatus(string status)
    {
        IList<JobTitle> jobTitles;

        switch (status)
        {
            case "All":
                jobTitles = jobTitleRepository.GetAll();
                break;
            case "Active":
                jobTitles = jobTitleRepository.GetActive();
                break;
            case "Inactive":
                jobTitles = jobTitleRepository.GetInactive();
                break;
            default:
                jobTitles = new List<JobTitle>();
                break;
        }
    }

我认为 switch 语句中的代码太多而不能放在控制器中，所以我将其提取到服务中，然后该服务进行适当的存储库调用。例如：

public class JobTitleService : JobTitleRepository, IJobTitleService, IJobTitleRepository
{
    public JobTitleService(ISession session) : base(session) { }
    public IList<JobTitle> GetJobTitlesByStatus(string status)
    {
        IList<JobTitle> jobTitles;

        switch (status)
        {
            case "All":
                jobTitles = base.GetAll();
                break;
            case "Active":
                jobTitles = base.GetActive();
                break;
            case "Inactive":
                jobTitles = base.GetInactive();
                break;
            default:
                jobTitles = new List<JobTitle>();
                break;
        }

        return jobTitles;
    }
}

我个人认为这很好用，特别是因为我使用依赖注入将服务放入控制器。我有以下问题：

1）您认为从控制器中提取switch语句逻辑是一个好主意吗？
2）您是否认为让 JobTitleService 从 JobTitleRepository 继承比将 IJobTitleRepository 传递给 Service 的构造函数（使用依赖注入）更好？
3) 用于 JobTitleService 的设计模式是否有特殊名称？

4

2 回答 2

3

  1. 是的 - 您的控制器应该负责选择结果、准备模型，然后将模型传递给视图进行渲染。其他一切都应该委托给其他地方，通常是服务。直接取自维基百科：

    控制器接收输入并通过调用模型对象来启动响应。控制器接受来自用户的输入并指示模型和视口根据该输入执行操作。

  2. 不，您的服务不应该从存储库继承。该服务需要与存储库协作才能完成其功能 - 因此它是一种“有”而不是“是”的关系。现在这可能并不明显，因为您的服务只是对存储库的传递，但是一旦您的服务开始执行服务应该执行的操作（协调一个或多个协作者的操作），它就会立即变为显而易见，因为您只能从其中一位合作者那里继承。

    实际上，在这种情况下，如果您的服务只是作为存储库的直接包装器，它不会添加任何内容，而只是一个间接层——如果它保持那么简单，我会放弃它并直接查询存储库。通常，尽管事情不会那么简单。

  3. 不，不是。

于 2010-06-24T21:45:43.030 回答
2

1）是的，业务逻辑不应该在控制器中。控制器实际上只是将表示连接到逻辑。理想情况下，逻辑是以一种更面向对象的方法执行的，而不是您在此处使用的更程序化的方法，但不要因此而被劝阻。只要代码简单且可支持，程序化就不是一件坏事。此设计为您所做的是允许您在需要时将服务类移动到实际的单独服务中。

2）我无法量化它，但我会犹豫是否要从存储库继承服务。在这个特定的设计中，我将服务视为存储业务逻辑过程的地方，并且将存储库作为持久性感知组件注入（理想情况下，业务逻辑不应该是持久性感知的）。我只是认为它更清晰地分离了关注点，并且随着系统的增长更容易完全理解设计。但这可能只是我个人的看法。

3）我确信有一个正式的名字可以放在简历上的某个地方：）我想到了“面向服务的架构”以及其他流行语。我从来不擅长术语，所以在这方面我帮不上什么忙。但是有很多关于这个主题的阅读材料。对于这类事情，这看起来不错：http: //msdn.microsoft.com/en-us/library/ms954638.aspx 也许也可以在这里寻找资源： http: //www.soapatterns.org/

于 2010-06-24T20:44:30.797 回答