0

Background

I am developing a WPF project.

This is the basic structure:

  • User Interface (WPF Project);
  • Interfaces (class library, contains all the interfaces and the entities used by the application;
  • Modules (every module contains the logic of a specific argument, e.g. File Management, and can eventually contains Wpf User Controls).

In the WPF Controls, to facilitate the binding operations I have created a BaseViewModel class which contains a Raise method that automates the binding mechanism (for further details, I used a technique similar to that one described in this article).


The problem

Understand which is the best way to separate Presentation form from the Business form in the entities classes.


The case

In the Interfaces project I have, for instance, the class User

public class User
{
    public virtual string Name { get; set; }

    // Other properties
}

In one of the modules I need to use the User class and to bind its properties to the User Interface controls. To do so I have to use a custom implementation of the get and set keywords.

At first point, I thought to create a class in the Module called, for instance, ClientUser and override the properties that I need:

public class ClientUser : User 
{
    private string name;

    public override string Name { get { return name; } set { Raise(out name, value); } }

    // Other properties
}

The problem is the Raise method, which is declared in the BaseViewModel class, but due to C# single inheritance constraint, I can't inherit from both classes.

Which is the right way to implement this architecture?

migrated from codereview.stackexchange.com Jul 22 '14 at 22:10

This question came from our site for peer programmer code reviews.

  • None of the code you show uses any MEF (Managed Extensibility Framework, by the way) or Prism, so I'm not sure how much either matters. Really, your question is about how to deal with inheritance. – Magus Jul 22 '14 at 22:34
  • You're right. I edited my question removing any reference to those frameworks. – simoneL Jul 23 '14 at 9:05
1

Use interfaces

public interface IUser
{
    string Name { get; set;}
}

And now you can have two implementations,

public class User : IUser
{
    public string Name { get; set; }
}

and

public class ClientUser : BaseViewModel, IUser
{
   private string _name;
   public string Name
   {
       get
       {
           return _name;
       } 
       set
       {
          Raise(out _name, value); 
       }
   }

}

As a positive side effect, you got rid of the virtual.

If your client user is simply a viewmodel for a user entity (which it seems to be), you most likely want a different design. Given IUser and User from above, you would write a viewmodel class:

public UserViewModel : BaseViewModel
{
    private readonly IUser _user;
    UserViewModel(IUser user)
    {
        _user = user;
    }

    public string Name
    {
       get
       {
           return _user.Name;
       } 
       set
       {
          _user.Name = value;
          Raise(out _name, value); 
       }
   }

}
  • The only disadvantage is that using the interfaces I have to implement all the member, even in the case I need a custom implementation only for one property (sometimes you don't have to bind every single property of the Model class). – simoneL Jul 23 '14 at 10:35
  • Not really. You can still inherit classes from classes, it does not mean that there is a 1:1 corresponence between interface and implementation. You can easily have a base class that implements the shared functionality, and inherit this from both User and ClientUser, where you implement the specific functionality, and only have the : IUser on the User and ClientUser (but not on the shared base). – Wilbert Jul 23 '14 at 10:39
  • Well, the ClientUser to use the Raise method must inherit from the BaseViewModel class. Because the Raise method is a User Interface concept (it is used to allow the Wpf Binding), I think it's wrong to mark also the User entity as a BaseViewModel child. – simoneL Jul 23 '14 at 10:50
  • I think you misunderstand the exact benefit of using interfaces. The interfaces allow you to decouple the 'how to use' (the interface) from 'how it's written' (the implementation). You can also use the User implementation inside client user and forward all calls with identical behavor. Or whichever way best satisfies your requirements. This is why using interfaces is the solution here. – Wilbert Jul 23 '14 at 11:35
  • Also, you most likely only use the BaseViewModel because you don't want to implement the ugly Wpf NotifyPropertyChanged logic in each class. I would suggest you look into MVVM frameworks such as Caliburn Micro that solve all those issues for you. – Wilbert Jul 23 '14 at 11:38

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.