MVVM and layering, implementing the Service Layer

Question

I am building an MVVM application. I'm trying to structure my application like this:

I don't know if this approach is common in MVVM. Anyways, the ViewModel uses the Service Layer to e.g populate the Model or ObservableCollection it is wrapping. To make use of its services, the ViewModel has a field that holds an abstraction of the service, like so:

IService service;

Because I use Linq to query the database, I have entities that have the same names as my domain names. To let the ViewModel be unaware of the Service Layer/Database entities, I need the Service Layer to give back a Domain Model instead of a Linq generated database entity. I do that by doing the following (an example of something I am working on at work):

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);
   }
}

There are a couple of things I am unhappy/unsure about:

• Is this a good way of structuring in combination with MVVM?
• I am forced to use Models.ItemType to make it different from the ItemType coming from the database. Is this unavoidable?
• I'm giving back a ObservableCollection - maybe something else would be better to give back and then somewhere make what I returned an ObservableCollection?
• Just in general, what could be improved or what could be a mistake of judgement you see I made?

Thanks :-)

Answer 1

There's just no reason to recreate the Data Objects that Linq creates for you. Just pass them along to the ViewModel an you'll be fine. It might seem like you HAVE to create a decoupling between the Domain and the ViewModel, but since these Entities only contain properties and not logic, it's ok to pass them along, and it would also be oh-so-much-easier to program.

everything else is very much current. one only thing is I wouldn't use LinqToSql, but instead EntityFramework. looks rather the same only L2SQL is an abandon thing by MS.