下面是我的最佳实践代码片段:

    public class UserController : Controller
    {
        private readonly IUserService userService;
        private readonly IBuilder<User, UserCreateInput> createBuilder;
        private readonly IBuilder<User, UserEditInput> editBuilder;

        public UserController(IUserService userService, IBuilder<User, UserCreateInput> createBuilder, IBuilder<User, UserEditInput> editBuilder)
        {
            this.userService = userService;
            this.editBuilder = editBuilder;
            this.createBuilder = createBuilder;
        }

        public ActionResult Index(int? page)
        {
            return View(userService.GetPage(page ?? 1, 5));
        }

        public ActionResult Create()
        {
            return View(createBuilder.BuildInput(new User()));
        }

        [HttpPost]
        public ActionResult Create(UserCreateInput input)
        {
            if (input.Roles == null) ModelState.AddModelError("roles", "selectati macar un rol");

            if (!ModelState.IsValid)
                return View(createBuilder.RebuildInput(input));

            userService.Create(createBuilder.BuilEntity(input));
            return RedirectToAction("Index");
        }

        public ActionResult Edit(long id)
        {
            return View(editBuilder.BuildInput(userService.GetFull(id)));
        }

        [HttpPost]
        public ActionResult Edit(UserEditInput input)
        {           
            if (!ModelState.IsValid)
                return View(editBuilder.RebuildInput(input));

            userService.Save(editBuilder.BuilEntity(input));
            return RedirectToAction("Index");
        }
}

在我们的例子中，我们将模型和控制器放在一个独立于视图的项目中。

根据经验，我们已经尝试移动和避免大多数ViewData[”…]的东西，因此我们避免了类型转换和魔术字符串，这是一件好事。

ViewModel还包含一些常见的属性，如列表的分页信息或用于绘制面包屑和标题的页眉信息。在我看来，此时基类包含了太多的信息，我们可以将其分为三部分，基本视图模型中99%的页面的最基本和必要的信息，然后是列表模型和表单模型，其中包含了该场景的特定数据并继承自基类。

最后，我们为每个实体实现一个视图模型来处理特定的信息。

就我个人而言，我建议如果ViewModel不是微不足道的，那么使用一个单独的类。

如果你有多个视图模型，那么我建议至少在一个目录中划分它。如果稍后共享视图模型，则目录中隐含的名称空间可以更容易地移动到新的程序集。

我将我的应用程序类保存在一个名为“Core”的子文件夹中(或一个单独的类库)，并使用与KIGG示例应用程序相同的方法，但做了一些轻微的更改，以使我的应用程序更加DRY。

我在/Core/ViewData/中创建了一个BaseViewData类，其中存储了常见的站点属性。

在此之后，我还在同一个文件夹中创建了所有的视图ViewData类，然后从BaseViewData派生并具有视图特定的属性。

然后我创建一个ApplicationController，我所有的控制器都是从它派生出来的。ApplicationController有一个通用的GetViewData方法，如下:

protected T GetViewData<T>() where T : BaseViewData, new()
    {
        var viewData = new T
        {
           Property1 = "value1",
           Property2 = this.Method() // in the ApplicationController
        };
        return viewData;
    }

最后，在我的控制器动作中，我做以下工作来构建我的ViewData模型

public ActionResult Index(int? id)
    {
        var viewData = this.GetViewData<PageViewData>();
        viewData.Page = this.DataContext.getPage(id); // ApplicationController
        ViewData.Model = viewData;
        return View();
    }

我认为这工作得很好，它保持你的视图整洁，你的控制器瘦。

按类别划分类(控制器、视图模型、过滤器等)是毫无意义的。

如果你想为你的网站(/)的Home部分写代码，然后创建一个名为Home的文件夹，并在那里放置HomeController, IndexViewModel, AboutViewModel等，以及Home操作使用的所有相关类。

如果你有共享类，比如ApplicationController，你可以把它放在项目的根目录。

为什么要分离相关的东西(HomeController, IndexViewModel)，而把完全没有关系的东西放在一起(HomeController, AccountController) ?

我就这个话题写了一篇博客。

我为每个视图创建了所谓的“ViewModel”。我把它们放在MVC Web项目中一个名为ViewModels的文件夹中。我根据它们所代表的控制器和动作(或视图)来命名它们。所以如果我需要传递数据到会员控制器上的注册视图，我创建了一个MembershipSignUpViewModel.cs类，并把它放在ViewModels文件夹中。

然后我添加必要的属性和方法，以促进数据从控制器传输到视图。我使用Automapper从我的ViewModel到域模型，如果需要的话再返回。

这也适用于包含其他viewmodel类型属性的复合viewmodel。例如，如果你在成员控制器的索引页上有5个小部件，并且你为每个分部视图创建了一个ViewModel——你如何将数据从index动作传递给分部?你在MembershipIndexViewModel中添加一个MyPartialViewModel类型的属性，当呈现部分时，你将在Model.MyPartialViewModel中传递。

这样做允许您调整部分ViewModel属性，而不必更改Index视图。它仍然只是传入模型。MyPartialViewModel所以当你所做的只是向partial ViewModel添加一个属性时，你就不太可能需要通过整个partial链来修复一些东西。

我还将添加命名空间“MyProject.Web”。ViewModels”到网络。配置，以便允许我在任何视图中引用它们，而无需在每个视图上添加显式的import语句。只是让它更干净一点。