0

那么下一个例子Controller有效吗?或者这样的逻辑应该在其他地方?据我了解,我们需要使用DTO在层之间传输数据,所以如果我们通过层JsonResultViewModelBussinesLogic层传递,它会出错吗?那么这个例子对了,专门用于ViewModel创建的逻辑可以在controller

        [HttpPost]
        [ValidateAntiForgeryToken]
        public JsonResult UploadImage(HttpPostedFileBase file)
        {
            var result = UploadedImageHandler.UploadFile(file);
            JsonResult json;

            if (result != null)
            {
                var uploadImageViewModel = new UploadedImagesViewModel
                {
                    foo = result.foo
                    //here some values from result goes to ViewModel
                };
                var uploadResult = new UploadResultViewModel
                {
                    Preview = new PreviewViewModel 
                    {
                        bar = result.bar 
                        //etc.
                    },
                    UploadedImage = uploadImageViewModel
                };
                json = new JsonResult
                {
                    Data = uploadResult,
                    ContentType = "text/html"
                };
            }
            else
            {
                json = new JsonResult
                {
                    ContentType = "text/html"
                };
            }

            return json;
        }
4

1 回答 1

1

在我看来是正确的。

ViewResult 和 JsonResult 都是特定于表示层的东西,而不是实际的业务逻辑,因此理所当然地属于控制器。

一些额外的(理论上的)思考:从技术上讲,在纯 MVC 原则下,控制器甚至不应该知道它正在呈现什么样的视图(json 或 html),并且该部分在技术上应该由另一个 MVC 处理动作过滤器。但是在大多数现实世界的场景中(在 .NET 世界中),这种模式很少使用,而上面的模式是最常见的(因此我们甚至有 JsonResult 之类的东西)。所以可以说它不是很重要。但是,即使您以这种方式对其进行架构,该操作过滤器仍将位于 Web 层(MVC 项目)中,而不是位于业务层中。

但是,是的,任何专用于 ViewModels 的逻辑都应该始终位于控制器(“web”/表示层)中,而不是业务层中。业务层甚至不应该知道 ViewModel 的存在(在理想情况下,业务层将是一个单独的程序集,完全不知道您的 Web MVC 程序集,甚至看不到这些类)。然后从业务层传回一个“业务对象”(也称为“域”对象),然后将其转换为控制器内部的 ViewModel(仅针对演示文稿)并将其传递给风景。

于 2014-05-09T06:10:18.930 回答