I'm quite new to stuff like DI, MVVM and WPF altogether, so it's fairly possible this reads like a giant WTF...I have defined an interface in my business layer, ISomeEntity; then in my data layer, I have a public class SomeEntity : ISomeEntity entity type. The thing to note here  is that the business layer does not reference the data layer.In the presentation layer, I can list these items, given that my window's ViewModel has a IEnumerable<ISomeEntity> property (or should it be IEnumerable<SomeEntityViewModel>?).Now I wanted to be able to mark a list item as to be deleted, and since I'm eventually going to have a whole bunch of such deletable types I created an IDeletable interface.The SomeEntity type in the data layer doesn't need to know about IDeletable, so I implemented the interface in a SomeEntityViewModel : ISomeEntity, IDeletable class, in the presentation layer (part of me is starting to think it should be defined in the business/domain layer instead).The problem I'm having, is that my model is spitting out ISomeEntity, which really is SomeEntity from the data layer: I need a way to convert from SomeEntity to SomeEntityViewModel, and given that SomeEntityViewModel is declared in the presentation layer, my only option seems to have my ViewModel class have a constructor like this:public SomeEntityViewModel(ISomeEntity poco){    // set the properties from the POCO implementation}...and then in the class that holds the presentation logic, I can bridge between the two implementations by doing something like this:_viewModel.Items = _model.SelectThoseItems() // returns IEnumerable<SomeEntity>                         .Select(e => new SomeEntityViewModel(e))                         .ToList();...and it works, but somehow doesn't feel right... or does it? Given ISomeEntity, SomeEntity, SomeEntityViewModel and IDeletable, what would be the common or normal way of implementing this? Or do I have it all wrong?
Converting between data and presentation types
c#;mvvm;inversion of control
You ideally don't want to have to implement the members of ISomeEntity that are irrelevant for the UI. For example if your engine type's interface has .ConnectionString or your UI might want .UserName .Password etc. without any reference of a connection string until the .ToSomeEntity builder is called.So I don't think it's unusual to have separate types for the view that encapsulate your engine types rather than implement them (it's what I do, anyway). This also means that changes to the interface or base class do not necessarily require changes in UI project.