Как я могу рефакторинг мой код доступа к базе данных за пределами моего проекта MVC, но сохранить свои ViewModel внутри?

Я понимаю, чего вы хотите добиться, и должен вам сказать: это абсолютно normal для повторного использования одних и тех же ViewModels для разных слоев пользовательского интерфейса. В конце концов, VM является частью шаблона MVVM, и этот шаблон-все о отделения проблемы. И, разделение означает возможность замены слоев нижнего уровня другими реализациями. Это is назначение отдельных программных слоев (среди прочего).

1. для начала, вы необходимо предположить, что ваш веб-проект MVC основан на MVVM. Это поможет Вам принимать правильные решения. Я думаю, вы уже сделали это, так как вы используете ViewModel термин.
2. сделайте ViewModels независимой от платформы. Возможно, и это не имеет ничего общего с SelectListItem. В конце концов, SelectListItem просто содержит пару текст/значение параметра, а также флаг, выбран он или нет. Очевидно, что вы можете выразить ту же информацию по-другому. После прохождения этого родового вида ViewModel в MVC, вы можете преобразовать общий "SelectListItem" в MVC SelectListItem. Да, это своего рода сопоставление, и не имеет значения, происходит ли оно в представлении MVC или перед передачей его в представление. Но это должно произойти на уровне пользовательского интерфейса (веб-проект MVC), так как это проблема отображения платформы.
3. вы упомянули код доступа к данным: это отдельный программный слой, обычно абстрактно вводимый в ViewModels. Я не предвижу никаких проблем с этим часть.

следовательно, у вас будут разные программные слои (скорее всего, в разных библиотеках .NET): слой доступа к данным, слой ViewModel, веб-слой MVC.

существует возможность иметь MVC ViewModels также (один передается от контроллера к виду), определенные в проекте MVC, но они будут просто обрабатывать (возможно, принимая) общие ViewModels и подвергая вещи в MVC View-конкретных терминах (отображение, наследование, ваше воображение?). И это тоже нормально - в конце концов, MVC-это веб-интерфейс, и у него определенно есть отличия от платформы, которые должны обрабатываться на уровне платформы, а не раньше. MVC specific ViewModel будет хорошим местом для обработки сопоставления от generic до MVC SelectListItem.

как только этот рефакторинг будет выполнен, ничто не помешает вам реализовать другое приложение UI layer - Console, которое вы упоминаете, используя то же самое generic ViewModels как другой уровень пользовательского интерфейса - Веб-проект MVC. При использовании универсальных ViewModels в консольном приложении, если вы сталкиваетесь с проблемами, специфичными для консольной платформы, вы можете придумать специфические для платформы ViewModels таким же образом, как я объяснил выше для специфичных для MVC ViewModels.

вы можете создавать viewmodels в контроллере с методами расширения:

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

создать этот SomeModelExtensions в вашем проекте mvc

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

В общем, я использую следующую настройку / архитектуру при размещении приложения MVC, где мне может потребоваться повторно использовать модели:

проект MVC: все, что связано с интернетом. Я определяю ViewModels здесь и сопоставляю их с моделями домена.

Models Project: библиотека классов со всей логикой домена.

проект репозитория: это библиотека классов, которая обращается к БД и моделям доменов.

способ его работы заключается в том, что проект MVC будет использовать (надеюсь, введена) библиотека репозитория, чтобы получить модель домена и сопоставить ее с собственной ViewModel.

Если вы также хотите отделить отображение, вы можете поместить слой отображения, как предлагали другие (используя AutoMapper в конечном итоге), в отдельный проект. Слой сопоставления будет ссылаться на репозитории (и модели доменов), в то время как приложение MVC будет ссылаться только на слой сопоставления.

проблема в том, что слой отображения при создании ViewModels будет нуждаться в ссылка на систему.Сеть.Mvc, как вы узнали, и вы не можете избежать этого. Вот почему другие сказали, и я согласен, что у вас должен быть слой отображения для каждого проекта.

хороший способ обойти это-иметь дополнительный общий слой отображения с классами отображения, определенными для общих случаев (например, электронная почта). Затем в определенных дочерних классах вы можете определить отображение для определенных случаев (например, в зависимости от системы.Сеть.В MVC).

Так конец стека будет что-то вроде следующего, зависимости идут вниз. Конечно все должно быть в интерфейсе.

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

вышеизложенное не является свободной борьбой, и, вероятно, усилие разделения отображения на части не стоит свеч, если есть только один или два общих случая. Таким образом, от общего картографа вниз вы свободны от системы.Сеть.Библиотека Mvc, в то время как выше вы можете забыть о Коде доступа к БД (в некотором смысле картограф будет выступать в качестве репозитория для приложения).

Я предполагаю, что MVC web будет использовать те же данные, что и консольное приложение + дополнительные поля, верно?

Итак, как насчет наследования вашей ViewModel от модели? Таким образом, Вы сможете повторно использовать модель и получать пользовательские поля в ViewModel по мере необходимости.

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


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