如何在MVC项目之外重构数据库访问代码，而将viewmodel保存在内部?

I have an asp.net-mvc website with the following folders:

我有一个asp.net-mvc网站，有以下文件夹:

Controllers
控制器
Scripts
脚本
Views
的观点
ViewModels
视图模型
Models
模型
DomainModel
DomainModel

I now want to access a lot of this business logic and database access code and data in another .net app (a windows console app so not web at all) so i am refactoring to remove as much stuff as possible outside of the MVC project and into other projects in the solution so that code could be shared with this other solutions.

我现在想获得很多的业务逻辑和数据库访问代码和数据在另一个。net应用程序(一个windows控制台应用程序不是web)所以我重构消除尽可能多的东西以外的MVC项目和其他项目在解决方案,以便代码可以共享其他解决方案。

I have 2 main issues;

我有两个主要问题;

My main issue is that I am struggling to find a place to put the code that generates the ViewModel because a lot of this code I would like to reuse in my console app as the console app sends email which requires the same data that is in the view.

我的主要问题是,我努力找个地方把生成的代码ViewModel因为很多这个代码我想重用我的控制台应用程序控制台应用程序发送电子邮件,需要相同的数据视图。
Another main issue is that i am struggling to see how i can move my database access code out of the MVC project while still having the ViewModels inside when many of my functions that instantiate my viewmodels start with a bunch of database access code.

另一个主要问题是，我正在努力查看如何将我的数据库访问代码移出MVC项目，同时，当我的许多函数实例化我的视图模型时，我的视图模型从一堆数据库访问代码开始。

Here is a bit of the detail and my process so far:

这里有一些细节和我的过程:

Step 1 - Move DomainModel into another project - success

So moving the DomainModel project was simple (as that was a lot of raw objects with some business logic on top - nothing web about it).

因此，移动DomainModel项目很简单(因为上面有很多原始对象，上面有一些业务逻辑——没有任何关于它的web)。

Step 2 - Thin out controllers - success

I have thinned out as much of my controllers as possible and moved any business logic or complicated data access logic into the Models folder. When i tried to move the models folder outside the MVC project a few things broke:

我尽可能地减少了我的控制器，并将任何业务逻辑或复杂的数据访问逻辑转移到模型文件夹中。当我试图将models文件夹移到MVC项目之外时，一些事情发生了:

Step 3 - Attempt to move Models folder outside MVC Project - struggle

In thinning out the controllers, I have a number of different controller actions that go to a model class and return my ViewModel that i pass back into the view. Something like this (in my controller class):

在细化控制器时，我有许多不同的控制器操作，这些操作进入模型类并返回我传递给视图的ViewModel。类似这样的东西(在我的控制器类中):

 public ActionResult ApplicationDetail(int id)
 {
      AppDetailViewModel applicationViewModel = Model.GenerateAppDetailViewModel(id);
      return View(applicationViewModel);
 }

So files in my Model folder are dependency on the ViewModel classes. I do want to centralize the GenerateAppDetailViewModel() function as that is used in multiple different controllers. Also, in my console app (which sends out email, i often want to get all the data that happens to be on some view so my code "wants" to leverage the viewmodel as well .. if i move it out of the MVC project then I can reuse but i think have the dependency issue (clearly i don't need SelectListItem in my console app but in other cases where they are just container objects of different data needed to generate a view I do want to reuse)

我的模型文件夹中的文件依赖于ViewModel类。我确实想集中GenerateAppDetailViewModel()函数，因为它在多个不同的控制器中使用。另外，在我的控制台应用程序(它会发送电子邮件)中，我经常希望获得某些视图上的所有数据，因此我的代码“想”利用viewmodel。如果我移动它的MVC项目我可以重用,但我想有依赖问题(显然我在控制台应用程序不需要SelectListItem但是在其他情况下,他们只是容器对象所需的不同的数据来生成一个视图我想重用)

or another thing that broke was the dependency on:

另一件崩溃的事情是依赖:

System.Web.Mvc

because I have a lot of code that:

因为我有很多代码

queries a table in a database
查询数据库中的表
Converts that into a collection of objects (i am using nhibernate)
将其转换为对象集合(我正在使用nhibernate)
Convert that into either some DTO object (which is sitting in ViewModels folder) or a List of SelectListItem objects (to be used to populate dropdowns in the view) which is part of System.web.mvc.
将其转换为某个DTO对象(位于ViewModels文件夹中)或SelectListItem对象列表(用于填充视图中的下拉列表)，这是System.web.mvc的一部分。

I wanted to look for suggestions on the best way to break out this dependency so i can move as much code out of the MVC project as possible for reuse.

我想寻找关于打破这种依赖关系的最佳方法的建议，这样我就可以从MVC项目中移出尽可能多的代码以供重用。

The issue is that if i try to suck my ViewModel code into the Model folder and into another project then again i get stuck because the ViewModel classes have a lot of dependency on

问题是，如果我试图将我的ViewModel代码放入模型文件夹和另一个项目中，那么我又会陷入困境，因为ViewModel类有很多依赖性

System.Web.Mvc

due to things like SelectListItem.

因为像SelectListItem。

Should i have 2 view models folders (one in the MVC project that has specific system.web.mvc references and another one that sits in a different project?). It seems like the dependency on SelectListItem is what keeps causing the contention

我应该有两个视图模型文件夹(一个在MVC项目中，有特定的system.web。mvc引用和另一个位于不同项目中的引用?)似乎是对SelectListItem的依赖导致了持续的争用

In most examples that i have seen ViewModels do have a dependency on System.Web.Mvc such as this tutorial

在我看到的大多数示例中，viewmodel确实依赖System.Web。像本教程一样的Mvc

I have seen these questions:

我看到了这些问题:

Asp.Net MVC SelectList Refactoring Question?
Asp。Net MVC选择列表重构问题?
Where should selectlist logic sit in ASP.NET MVC, view, model or controller?
选择列表逻辑在ASP中的位置。NET MVC，视图，模型还是控制器?

which are sort of related but not sure they answer my specific overall refactoring question stated.

它们是相关的，但不确定它们是否回答了我提出的具体的重构问题。

5 个解决方案

#1

View models are specific to the particular application. I guess that the view models would differ between your web application and your console application. So have each application define its own view models and the corresponding mapping between the domain models and the view models. Don't have your domain models posses methods that convert them to view models because this way you are completely tying your domain layer to the UI layer which is the worst thing to happen. Use a mapping layer (which will be specific to each application type). AutoMapper is a great example of a mapping layer that you could have.

视图模型是特定于特定应用程序的。我想您的web应用程序和控制台应用程序之间的视图模型是不同的。因此，让每个应用程序定义自己的视图模型以及域模型和视图模型之间的对应映射。不要让你的域模型将它们转换为视图模型，因为这样你就完全把你的域层绑定到UI层了，这是最糟糕的事情。使用映射层(具体到每个应用程序类型)。AutoMapper是一个很好的映射层示例。

Don't even try to reuse ASP.NET MVC view models in a console application. As you have already found out they will contain references to System.Web.Mvc because for example a dropDownList in ASP.NET MVC is represented with the IEnumerable<SelectListItem> class whereas in a Console Application, god knows, maybe an IEnumerable<SomeItemViewModel>.

不要尝试重用ASP。NET MVC视图模型在控制台应用程序中。正如您已经发现的，它们将包含对System.Web的引用。Mvc，因为例如在ASP中的下拉列表。NET MVC使用IEnumerable 类来表示，而在控制台应用程序中，天晓得，可能是IEnumerable - SomeItemViewModel>。

Conclusion: View models and mapping back and forth between the domain and view models belong to the UI layer (a.k.a ASP.NET MVC, Console, WPF, ...).

结论:视图模型和在域和视图模型之间来回映射属于UI层(a.k)。一个ASP。NET MVC，控制台，WPF，…)

#2

I understand what you want to achieve, and I must tell you: it's absolutely normal to reuse the same ViewModels for different UI layers. After all, VM is part of MVVM pattern, and that pattern is all about separating concerns. And, separation means the ability to replace lower-level layers with another implementations. That is the purpose of separate software layers (among others).

我理解您想要实现什么，我必须告诉您:为不同的UI层重用相同的视图模型是绝对正常的。毕竟，VM是MVVM模式的一部分，这个模式是关于分离关注点的。而且，分离意味着能够用另一种实现替换较低级别的层。这就是分离软件层的目的。

For the beginning, you must assume that your MVC web project is MVVM-based. That will mentally help you make correct decisions. I guess you already did this since you use ViewModel term.
首先，您必须假定您的MVC web项目是基于mvvmvm的。这会在精神上帮助你做出正确的决定。我想你已经这样做了，因为你使用了ViewModel术语。
Make ViewModels become platform independent. It's possible, and it has nothing to do with SelectListItem. After all, SelectListItem simply contains the option text/value pair, plus the flag whether it's selected or not. You obviously can express the same information in a different way. After passing this Generic kind of ViewModel to the MVC, you can convert the generic "SelectListItem" to the MVC SelectListItem. Yes, it is sort of mapping, and it does not matter whether it takes place in the MVC view or before passing it to the View. But it must happen on the UI layer (MVC web project), since it's a platform specific mapping concern.
使视图模型成为平*立的。这是可能的，它与SelectListItem无关。毕竟，SelectListItem只包含选项文本/值对，以及它是否被选中的标志。显然，你可以用不同的方式表达相同的信息。在将这种通用类型的ViewModel传递给MVC之后，您可以将通用的“SelectListItem”转换为MVC SelectListItem。是的，它是一种映射，它是发生在MVC视图中，还是在传递给视图之前都没有关系。但是它必须发生在UI层(MVC web project)上，因为它是一个特定于平台的映射关系。
You mentioned data access code: that's a separate software layer, usually abstractly injected into the ViewModels. I foresee no problems with this part.
您提到了数据访问代码:这是一个单独的软件层，通常抽象地注入到viewmodel中。我预计这部分不会有问题。

Hence, you will end up having different software layers (most likely in different .NET libraries): Data Access Layer, ViewModel layer, MVC Web layer.

因此，您最终将拥有不同的软件层(很可能在不同的. net库中):数据访问层、ViewModel层、MVC Web层。

There is a possibility of having MVC ViewModels as well (one passed from Controller to View) defined in the MVC project, but those will be simply handling (probably accepting) the generic ViewModels and exposing things in the MVC View-specific terms (mapping, inheritance, your imagination?). And this is normal too - after all, MVC is a web-based UI and it definitely has platform-specific differences that must be handled on the platform level, not before. MVC specific ViewModel would be a good place to handle the mapping from generic to MVC SelectListItem.

也有可能在MVC项目中定义MVC视图模型(从一个控制器传递到另一个视图)，但是这些只是简单地处理(可能接受)通用的视图模型，并以特定于MVC视图的术语(映射、继承、想象?)这也很正常——毕竟，MVC是基于web的UI，它肯定有特定于平台的差异，必须在平台级别上处理，而不是以前。MVC特定的ViewModel是处理从通用到MVC SelectListItem映射的好地方。

Once this refactoring is done, there's nothing stopping you from implementing another UI layer - Console application that you are mentioning, by utilizing the same generic ViewModels as the other UI layer - MVC Web project. When using the generic ViewModels in the console application, if you face the Console platform-specific issues, you can come up with the platform-specific ViewModels in the same way as I explained above for the MVC-specific ViewModels.

一旦完成了重构，就没有什么可以阻止您实现另一个UI层——您所提到的控制台应用程序，通过使用与其他UI层- MVC Web项目相同的通用视图模型。当在控制台应用程序中使用通用的viewmodel时，如果您面对控制台特定于平台的问题，您可以按照我在上面针对特定于mvc的viewmodel中所介绍的方式生成特定于平台的viewmodel。

#3

You can create viewmodels in controller with extension methods:

您可以使用扩展方法在控制器中创建viewmodel:

Controller:

控制器:

 public ActionResult ApplicationDetail(int id)
 {
      var model = _serviceLayer.GetSomeModel(id); 
      var viewModel = model.CreateInstance(model);      
      return View(viewModel);
 }

Create this SomeModelExtensions in your mvc project

在mvc项目中创建这个SomeModelExtensions

public class SomeModelExtensions {
      public AppDetailViewModel CreateInstance(this SomeModel model) {
           var viewModel = new AppDetailViewModel();
           // here you create viewmodel object from model with logic
           return viewModel;
      }
}

#4

In general I use the following setup/architecture when laying out an MVC app where I may need to reuse the models:

一般来说，我在设计MVC应用程序时，会使用以下的设置/架构，我可能需要重用这些模型:

MVC Project: everything web related. I define ViewModels here and map them to the domain models.

MVC项目:所有与web相关的内容。我在这里定义ViewModels并将它们映射到域模型。

Models Project: class library with all your domain logic.

模型项目:包含所有域逻辑的类库。

Repository project: This is a class library which access the DB and the Domain Models.

Repository项目:这是一个访问DB和域模型的类库。

The way it works is that the MVC project will use the (hopefully injected) Repository library to get the Domain Model and map it to its own ViewModel.

它的工作方式是MVC项目将使用(希望是注入的)存储库来获取域模型并将其映射到它自己的ViewModel。

If you want to separate the mapping as well, you can put the Mapping Layer, as others have suggested (using AutoMapper eventually), in a separate project. The mapping layer will reference the repositories (and the domain models), while the MVC app will only reference the Mapping layer.

如果您也想分离映射，您可以将映射层(正如其他人建议的那样(最终使用AutoMapper))放在一个单独的项目中。映射层将引用存储库(和域模型)，而MVC应用程序将只引用映射层。

The problem is that the mapping layer, in creating ViewModels, will need a reference to System.Web.Mvc as you found out and you cannot escape this. This is why others have said, and I agree, that you should have a mapping layer per project.

问题是，在创建viewmodel时，映射层需要对System.Web进行引用。Mvc就像你发现的那样，你无法摆脱它。这就是为什么其他人说，我同意，每个项目应该有一个映射层。

A nice way to get around this is to have a further generic mapping layer with mapping classes defined for the common cases (like the email). Then in the specific child classes you can define the mapping for specific cases (like the ones depending on System.Web.Mvc).

解决这一问题的一个好方法是使用一个更通用的映射层，其中包含为常见情况(如电子邮件)定义的映射类。然后，在特定的子类中，您可以为特定的情况(比如依赖于System.Web.Mvc的情况)定义映射。

So the end stack would be something like the following, dependencies going down. Of course everything should be interface based.

所以最终堆栈应该是这样的，依赖性会下降。当然，一切都应该基于接口。

    MVC App                      Console App
       |                            |
       |                            |
   MVC Specific Mapper         Console Specific Mapper
                 \               /  
                  \             /
                   \           /   
                   GenericMapper <- EmailMapper and EmailViewModel can be implemented here
                     |       |      
                     |       |
                Repository   |
                     |       |
                     |       |
                    DomainModels

The above is not struggle free and probably the effort of splitting the mapping apart is not worth the candle if there are only one or two common cases. That way, from the Generic Mapper down you are free from the System.Web.Mvc library, while above you are free to forget about DB access code (In a sense the Mapper will act as a Repository for the App).

上面的内容并不是免费的，如果只有一两个常见的情况，那么将映射拆分开来的努力可能并不值得。这样，从通用映射器到System.Web就不需要了。Mvc库，上面你可以*地忘记DB访问代码(在某种意义上，映射器将作为应用程序的存储库)。

#5

I assume the MVC web will use the same data as the console app + extra fields, right?

我假设MVC web将使用与控制台app +额外字段相同的数据，对吗?

so, what about inheritance your ViewModel from Model? That way you would be able to reuse the model and get custom fields on your ViewModel as needed.

那么，如何从Model继承ViewModel呢?这样，您就可以重用模型，并根据需要在视图模型上获取定制字段。

public class AppDetailModel
    {
        public int ID { get; set; }
        public string Name { get; set; }
    }


    public class AppDetailViewModel : AppDetailModel
    {
        public string ViewProperty { get; set; }
    }

#1