Is ViewModel creating logic count as "unprefered logic" in controller

Question

So is next example of Controller valid? Or logic like this should be somewhere else? As i understand we need to use DTO to transfer data between layers, so if we pass JsonResult or ViewModel from BussinesLogic layer, it will mistake? Then this example right, and logic dedicated to ViewModel creating can be in 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;
        }

Answer 1

Looks correct to me.

Both ViewResult and JsonResult are things specific to the presentation layer, not the actual business logic, and thus rightfully belong in the controller.

Some additional (theoretical) food for thought: Technically, under pure MVC principles, the controller is not even supposed to be aware what kind of view it is rendering (json or html), and that part is technically supposed to be handled by another MVC Action Filter. But in most real-world scenarios (in the .NET world) this kind of patter is very rarely used, and what you have above is most common (hence we even have stuff like JsonResult, etc). So it is arguably not very important. Even if you were to architect it that way, however, that Action Filter would still be in the web layer (MVC project), not in the business layer.

But yes, any logic dedicated to ViewModels should always be in the controller (the "web"/presentation layer) and never in the business layer. The business layer should not even be aware that ViewModels exist (in an ideal case, the business layer would be a separate assembly completely unaware of your Web MVC assembly, and wouldn't even see those classes). From the business layer, you would then pass back a "business object" (also known as a "domain" object), which you would then convert into a ViewModel (which is specific only to the presentation) inside your controller and pass that into the view.