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

...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?


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.

  • Awesome, looks like the tiny little bit I was missing. So the "presentation types" need to be completely distinct from the "data types" and they can't implement the same interface, which means the conversion needs to happen exactly where I'm having it... and that I need a "presentation type" for everything I need displayed - this encapsulation also solves the problem of the "Id" field that I need remembered but don't want displayed. – Mathieu Guindon Sep 3 '13 at 15:34
  • By the way, I think the downvotes are happening because this is a practical question about coding which would normally belong on Stack Overflow. 'Programmers' is meant for questions about 'general' issues regarding programming, like the languages themselves or computer science. – Robin Sep 4 '13 at 10:56
  • Hmm I thought it wasn't specific enough for SO! It should just be flagged as such then, downvoting for "doesn't belong here" is somewhat useless, especially without a comment.. – Mathieu Guindon Sep 4 '13 at 12:11
  • I've posted what came out of this on CR if you want to take a look :) – Mathieu Guindon Sep 4 '13 at 13:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.