MVVM и многослойность, реализующая сервисный уровень

Question

Я создаю приложение MVVM.Я пытаюсь структурировать свое приложение так:

Я не знаю, распространен ли такой подход в MVVM.В любом случае, ViewModel использует сервисный уровень, например, для заполнения Model или ObservableCollection, которую он упаковывает.Чтобы использовать свои сервисы, в ViewModel есть поле, содержащее абстракцию сервиса, например:

IService service;

Поскольку я использую Linq для запроса к базе данных, у меня есть сущности, имена которых совпадают с именамимои доменные имена.Чтобы ViewModel не знал о сущностях уровня обслуживания / базы данных, мне нужно, чтобы уровень обслуживания возвращал модель домена вместо созданной Linq сущности базы данных.Я делаю это, выполняя следующее (пример чего-то, над чем я работаю на работе):

ObservableCollection<ItemTypeViewModel> GetItemTypes()
{
   DataContextLocalDB dc = new DataContextLocalDB();
   ObservableCollection<ItemTypeViewModel> itemTypes = new ObservableCollection<ItemTypeViewModel>();

   foreach (ItemType itemType in dc.ItemTypes)
   {
      Models.ItemType type = new Models.ItemType();
      type.Name = itemType.Name;
      type.Description = itemType.Description;

      ItemTypeViewModel itemTypeViewModel = new ItemTypeViewModel(type);

      itemTypes.Add(itemTypeViewModel);
   }
}

Есть пара вещей, в которых я недоволен / не уверен:

• Это хороший способ структурирования в сочетании с MVVM?
• Я вынужден использовать Models.ItemType, чтобы отличать его от ItemType, поступающего из базы данных.Это неизбежно?
• Я возвращаю ObservableCollection - может быть, что-то еще было бы лучше вернуть, а затем где-нибудь сделать то, что я возвратил ObservableCollection?
• В общем, что может бытьулучшилось или что может быть ошибочным суждением, которое вы видите, я сделал?

Спасибо: -)

Answer 1

Нет никакой причины воссоздавать объекты данных, которые Linq создает для вас.Просто передайте их ViewModel, и все будет в порядке.Может показаться, что вы ДОЛЖНЫ создать развязку между Доменом и ViewModel, но, поскольку эти сущности содержат только свойства, а не логику, можно передавать их вместе, а также намного проще программировать.

все остальное очень актуально.Единственное, я бы не стал использовать LinqToSql, а вместо этого EntityFramework.выглядит примерно так же, только L2SQL - вещь, оставленная MS.

Answer 2

public partial class ItemType : EntityObject //this is your Entity Model
{
   public string Name{get;set;}
   public string Description{get;set;}
}

Вы не можете редактировать вышеуказанный раздел.

Если вы хотите расширить модель с помощью viewModel.Создать еще один класс

public partial class ItemType : EntityObject // this is your ViewModel class,this place on another file 
{// Important: in same namespace

   public void SomeMethod(){}
   public ICommand CustomCommand {get{...}}
   public string CustomProperty{
      get{ return localVar;}
      set{ localVar=value;
           onPropertyChanged("CustomProperty");
          }}
}

Наконец:

public IQueryable<ItemType> GetItemTypes{
   get{
    DataContextLocalDB dc = new DataContextLocalDB(); 
    return dc.ItemTypes;
   }
}