Question

我一直在阅读有关在ASP.NET MVC项目中放置业务逻辑的位置，我仍然无法明确某些事情。特别是在数据来自UI时执行计算或业务逻辑。

我使用EF的ASP.NET MVC应用程序。该应用程序是典型的3层应用程序。

    UI  - has View Models
    Domain (aka Service Layer) - has DTO classes
    DAL  - has EF entities

每个图层都有自己的C＃类，用于在图层之间传输数据 UI引用了Domain，Domain引用了DAL
应用程序的业务逻辑位于Domain（服务层）

通常，任何类型的业务逻辑/计算都在服务层中完成。当数据来自数据库时，这是正确的。

但是如果数据来自UI呢？

让我们说视图已经用几个字段呈现。 UI层中有相应的视图模型。用户更新一些字段并单击一个按钮，这将ajax POST发送到控制器操作。因此服务器现在已经填充了来自UI的视图模型。现在我想做一些计算并返回json数据。

 [HttpGet]
 public ActionResult Index(int id)
 {
   MyViewModel model = _service.GetModel(id);
   return View(model);
 }

 [HttpPost]
 public ActionResult Calculate(MyViewModel model)
 {
     // preform calculations but where??
     var differentmodel = PerformCalculations(model);
     return Json(someDifferentmodel);
 }

由于Domain图层无法访问视图模型，因此我无法将MyViewModel传递给Domain并在那里进行计算。
我在这里看到的一个选项如下

 public ActionResult Calculate(MyViewModel model)
 {
     1> Convert MyViewModel to DTO
     2> pass DTO to service layer for calculations
     3> get calculated DTO from service layer. 
     4> Convert DTO to differentViewModel

      return Json(differentViewModel);
 }

有很多背部＆amp;第四次映射，这似乎没必要。

有没有更好的方法？
在设计实践方面，可以在UI和Domain之间引入一个同时引用UI和Domain的新图层。这个新层将负责进行业务逻辑/计算。事实上，无论数据来自UI还是域，我都可以使用此层进行计算。这层是什么？（我知道技术上我可以这样做，但我想问的是推荐的设计实践）

Answer 1

你使这个变得不必要地变得复杂。要问的第一个问题是：“这个计算逻辑是仅与视图相关还是适用于其他地方，例如DAL？如果它只与视图相关，请将其放在视图模型上。如果它具有更广泛的适用性然后把它放在一个类库或者所有需要它的项目引用的东西中。在后一种情况下，你可能只是创建一个帮助类进行计算，而你只传入相关数据来制作那些计算。

然后，在UI层中，您可以使用视图模型或其他辅助类来专门处理视图模型。例如：

班级图书馆

public static class CalculationHelper
{
    public static int Add(int a, int b)
    {
        return a + b;
    }
}

<强> UI

public class MyViewModel
{
    ...

    public FooBarSum
    {
        get { return CalculationsHelper.Add(Foo, Bar); }
    }
}

OR

public static class UICalculationsHelper
{
    public static int Add(MyViewModel model)
    {
        return CalculationsHelper.Add(model.Foo, model.Bar);
    }
}

在MVC中，当数据来自UI时执行计算？

1 个答案: