asp.net MVC - 在视图中编写 C# 代码对性能有何影响，这些视图也可以在控制器/业务中编写

本文关键字：视图 影响 也可以 业务 控制器 性能 MVC net 代码 何影响 asp | 更新日期: 2023-09-27 17:56:30

我这样做是为了避免商务舱中出现额外的视图模型映射。例：

public class PatientInfoBusiness
{
    public List<PatientInfo> GetPatientInfo()
    {
        IPatientInfoService proxy = new VRFactory().GetPatientInfoServiceProxy();
        var piData= proxy.GetPatientInfoSectionData();
        //var patientInfoVM= new List<patientInfoVM>();
        //piData.ForEach( a => patientInfoVM.Add(
        //                                                          new patientInfoVM
        //                                                          {
        //                                                              AcknowledgedUserName = a.AcknowledgedUserName,
        //                                                              Description = a.Description,
        //                                                              PriorityCode = a.PriorityCode,
        //                                                              Status = a.Status
        //                                                          }
        //                                        )
        //                );
        return piData;
    }
}

将上述业务中的注释代码移至查看，循环浏览并以 HTML 显示。这样就不需要病人InfoVM视图模型了。但是我完全跳过了业务层，直接在视图中绑定了服务层中的实体！

asp.net MVC - 在视图中编写 C# 代码对性能有何影响，这些视图也可以在控制器/业务中编写

我认为可维护性与性能不应该是这里的问题。一切都与时间有关。开发/读取/修改解决方案所需的时间越少越好。因此，您需要将解决方案拆分为层。如果数据层发生了变化，则不必修改 gui 层。不应进行预优化。但是有一些技巧可以更有效地编写代码。

您可能会返回一个IEnumerable<patientInfoVM> 。这将创建懒惰patientInfoVM。这将仅在迭代时创建项。

public class PatientInfoBusiness
{
    public IEnumerable<PatientInfo> GetPatientInfo()
    {
        IPatientInfoService proxy = new VRFactory().GetPatientInfoServiceProxy();
        var piData= proxy.GetPatientInfoSectionData();
        return piData.Select(a => new patientInfoVM
        {
          AcknowledgedUserName = a.AcknowledgedUserName,
          Description = a.Description,
          PriorityCode = a.PriorityCode,
          Status = a.Status
        });
    }
}

如果您只迭代结果，则可以像这样使用它：

foreach(var patientInfo in GetPatientInfo())
{
    // do something.
}

但是，如果您需要多次使用结果，则应保留以下项目：

var patientInfoList = GetPatientInfo().ToArray();
foreach(var patientInfo in patientInfoList)
{
    // do something.
}
foreach(var patientInfo in patientInfoList)
{
    // do something.
}

没有任何硬指标，我只能提出我的意见，但在这里代替其他更受分析驱动的回应。

我会说是的，将业务逻辑放在单独的层中会导致开销略高，因此性能会降低。然后，我还要说，如果我用原始机器代码编写，我可以挤压更多的性能，但那太疯狂了。因此，以下是我为什么稍微差一点的性能值得的原因：

  • 在整个视图中混合的数据访问代码的维护将成为一场噩梦 - 您最终将多次重写相同的访问样板代码（因为您无法在其他视图中重用查询逻辑）
  • 视图通常是 JIT 编译的（除非你关闭它），并且智能感知通常不能完全赶上你正在做的事情，所以你可以将编译时错误泄漏到运行时
  • 通过视图进行调试很糟糕 - 它只是这样做
  • 混合你的表示代码和你的业务逻辑通常是一个"坏主意" - 主要是因为这两个问题变得过于混合
  • 您在示例中使用了List<>，这是一个性能较低的便利结构：所以可以，为什么不适用于 MVC？
  • 您如何在视图中处理错误？您是否捕获异常并输出不同的标记？这如何转化为显示模板、部分视图和其他类似的东西？

无论如何，这就是我的全部观点：只要问问自己为什么要使用这个框架，以及最后一滴性能可能会以其他方式花费你什么。但决定权在你。

相关文章：