【问题标题】:How can I clean my controller actions and reference up in my ASP.NET CORE 5 application? [closed]如何在我的 ASP.NET CORE 5 应用程序中清理我的控制器操作和引用? [关闭]
【发布时间】:2021-11-16 17:57:48
【问题描述】:

我的 Web 应用程序的前端有一个用户可以提交的表单,该表单与一个名为 Requirement 的模型相关联。因为创建和编辑数据只有一个表单,所以我需要一种方法来在我的控制器中处理这个过程。

为了让事情变得更简单,我将模型中传入的 Id 作为参考点并从那里开始工作。

Process_Requirement

这是点击提交时表单调用的操作。它查看传入的 Id,条件是如果它是 0,它是新的,它在 0 之上,它已经存在。

public async Task<JsonResult> Process_Requirement(Requirement model)
{
    //It's new
    if (model.Id == 0) {
        var create = await Create_Requirement(model);
        return Json(new { model = create });        
    }
    //It exists
    else {
        var update = await Update_Requirement(model);
        return Json(new { model = update });
    }
}

此父操作根据满足的条件引用以下两个操作。

public async Task<JsonResult> Create_Requirement(Requirement model) 
{
    try
    {
        var requirement = await _requirement.CreateAsync(model);
        return Json(new { success = true, data = requirement.Id, operation = "create" });                
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.Message);
    }
    return Json(new { success = false, data = model });
}

public async Task<JsonResult> Update_Requirement(Requirement model)
{
    try
    {
        var requirement = await _requirement.UpdateAsync(model);
        return Json(new { success = true, data = requirement.Id, operation = "update" });
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.Message);
    }
    return Json(new { success = false, data = model });
}

那么,这里有什么问题?好吧,我只是认为我在这里的方法并不像它应该的那样干净,笨拙,而且也许不太正确。是的,它有效!但我想确保我正在生成运行良好的流畅代码,并认为我会在这里发布它,看看人们的想法是什么以及我怎样才能做得更好?

【问题讨论】:

  • 这可能更适合Code Review
  • Code Review 发帖之前,请务必阅读A guide to Code Review for Stack Overflow users,因为那里有些事情的处理方式不同 - 例如。问题标题应该简单地说明代码做了什么,因为问题总是“我该如何改进?”。确保代码正常工作;如果可能的话,包括你的单元测试。您可能会收到一些建议,使其更高效、更易于阅读和更好地测试。

标签: c# entity-framework asp.net-core


【解决方案1】:

你违反了SRP原则

SRP:

单一职责原则 (SRP) 是一种计算机编程原则,它指出计算机程序中的每个模块、类或函数都应对该程序功能的单个部分负责,并且应该封装该部分...... .

您应该在后端有两个操作,一个用于创建,一个用于编辑 并且您必须使用相同的表单在前端创建两个状态。如果您的状态处于创建模式,则应调用 create api,如果处于编辑模式,则应调用 update api。

 public async Task<JsonResult> Create_Process_Requirement(Requirement model)
    {
        var create = await Create_Requirement(model);
        return Json(new { model = create });
    }

   public async Task<JsonResult> Update_Process_Requirement(Requirement model)
    {
        var update = await Update_Requirement(model);
        return Json(new { model = update });
    }

【讨论】:

  • 这个。前端方法应该是分开的,所以真的不需要“ProcessRequirement”,客户端应该酌情调用“Create”或“Update”。 OP 可能会发现将创建与更新的模型分开是有益的,因为系统通常允许用户在创建在编辑期间无法更改的记录时提供某些详细信息。 Create 没有 ID,而 Update 需要它。
【解决方案2】:

您的Update_RequirementCreate_Requirement 实际上是在做同样的事情,只是调用了两种不同的方法。您可以将这两种方法合并为一个。

    /// <summary>
    /// Create or Update Requirement object.
    /// </summary>
    /// <param name="model"></param>
    /// <returns></returns>
    private async Task<JsonResult> CreateOrUpdate_Requirement(Requirement model)
    {
        try
        {
            string operationValue = string.Empty;
            int requirementId;
            if(model.Id == 0)
            {
                operationValue = "create";
                requirementId = (await _requirement.CreateAsync(model)).Id;
            }
            else
            {
                operationValue = "update";
                requirementId = (await _requirement.UpdateAsync(model)).Id;
            }

            return Json(new { success = true, data = requirementId, operation = operationValue });
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
        }
        return Json(new { success = false, data = model });
    }

我不确定您的 await _requirement.CreateAsync(model)_requirement.UpdateAsync(model) 实际做了什么以及它们返回的值类型。你也可以合并它们。 您可以将您的主要方法更改为:

public async Task<JsonResult> Process_Requirement(Requirement model)
{
    return await CreateOrUpdate_Requirement(model);
}

【讨论】:

  • 不,一个函数应该做一件事,而且只做一件事。通过引入条件逻辑来合并方法与适当的重构完全相反。这些方法做类似的事情,不完全相同。
猜你喜欢
  • 1970-01-01
  • 2019-11-10
  • 1970-01-01
  • 2020-10-12
  • 1970-01-01
  • 2020-12-02
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多