Class design paradox

Question

I've got the need for a class that identifies what type of network join to be performed.

The network join can either be a Domain join a Workgroup join.

In the case of a Workgroup join I only need to know the Name of the workgroup to join.

In the case of a Domain join I need to know the Name of the domain to join as well as the Username and Password to use (let's ignore all concerns about security here, this is a scenario).

I then want to create a WPF UI for it similar to this:

http://documents.weber.edu/ctctools/sccm/images/osdnotes/9.png

Where the credentials portion of the GUI becomes disabled if the user picks a Workgroup join and enabled when they pick a Domain join (with the same being said regarding the name of the actual Workgroup/Domain to join).

And I want to be able to serialize/deserialize this data (again ignore security concerns, this is a scenario).

The way I see it I have two options:

Option 1

Create a solution similar to:

enum JoinType
{
    Domain,
    Workgroup
}

class NetworkJoin
{
    JoinType JoinType {get; set;}
    string Name {get;set;}
    string Username {get;set;}
    SecureString Password {get;set;}

    void Join()
    {
        // Join code for domain + workgroup
    }
}

This would allow me to easily do TextBoxUsername.IsEnabled = ViewModel.NetworkJoin.JoinType == JoinType.Domain.

However, because the class instance is serialized/deserialized it allows for an instance of this class to have JoinType = JoinType.Workgroup as well as having a Username/Password and it's an assumption (although a logical one) that what network join to do is based off of a check on the JoinType (rather than say, if (Username == null) { // workgroup join })

Which brings me to option 2

Option 2

Something similar to:

interface INetworkJoin
{
    string Name {get;set;}
    void Join();
}

class DomainJoin : INetworkJoin
{
    string Name {get;set;}
    string Username {get;set;}
    SecureString {get;set;}
    void Join()
    {
        // Domain join code
    }
}

class WorkgroupJoin : INetworkJoin
{
    string Name {get;set;}
    void Join()
    {
        // Workgroup join code
    }
}

Now it's impossible for you to create an object with the wrong properties or any assumption about what type of join will be performed because ambiguous parameters we passed.

In fact, normally this would be a much better solution. Except for the binding it to the UI.

My ViewModel would basically have a INetworkJoin NetworkJoin, which means my View would only see a INetworkJoin. It needs to know its concrete type in order to determine whether to show/not show the credentials objects, it needs to bind the Username TextBox to the Username property (which INetworkJoin doesn't have...), same for Password, etc etc.

Summary

If feels like neither of the solutions is really appropriate. The first provides an ambiguous join and the second would require finding out the concrete type of an interface, as well as accessing properties only available in the concrete type.

I imagine there has to be a better solution than either of these, but this is really all I can think of.

Any help would be appreciated.

Answer 1

You should have separate domain models and view models. View models also usually implement INotifyPropertyChanged and have additional properties e.g. to enable/disable buttons etc.

Domain Model:

abstract class NetworkJoin
{
    public string Name { get; set; }
}

class WorkgroupJoin : NetworkJoin
{
}

class DomainJoin : NetworkJoin
{
    public string Username { get; set; }
    public SecureString Password { get; set; }
}

View model (for sake of simplicity I am not showing the INotifyPropertyChanged implementation. Changes to Name, Username and Password would have to trigger OnPropertyChanged(nameof(IsOkButtonEnabled))):

class NetworkJoinViewModel
{
    private const int MinPasswordLength = 8;

    public JoinType JoinType { get; set; }
    public string Name { get; set; }
    public string Username { get; set; }
    public SecureString Password { get; set; }

    public bool IsOkButtonEnabled
    {
        get {
            switch (JoinType) {
                case JoinType.Domain:
                    return
                        !String.IsNullOrEmpty(Name) &&
                        !String.IsNullOrEmpty(Username) &&
                        Password != null && Password.Length >= MinPasswordLength;
                case JoinType.Workgroup:
                    return !String.IsNullOrEmpty(Name);
                default:
                    return false;
            }
        }
    }

    public bool IsLoginEnabled => JoinType == JoinType.Domain; // For password an username textboxes.

    public void Join()
    {
        switch (JoinType) { /* ... */  }
    }

    public NetworkJoin ToDomainModel() {
        switch (JoinType) {
            case JoinType.Domain:
                return new DomainJoin {
                    Name = Name,
                    Username = Username,
                    Password = Password
                };
            case JoinType.Workgroup:
                return new WorkgroupJoin {
                    Name = Name
                };
            default:
                return null;
        }
    }
}

Finally a view model factory (because I do not want to add a ToViewModel method to the domain model. The domain model should not know details about the view models):

static class NetworkJoinViewModelFactory
{
    public static NetworkJoinViewModel Create(NetworkJoin networkJoin)
    {
        switch (networkJoin) {
            case WorkgroupJoin workgroupJoin:
                return new NetworkJoinViewModel {
                    JoinType = JoinType.Workgroup,
                    Name = workgroupJoin.Name
                };
            case DomainJoin domainJoin:
                return new NetworkJoinViewModel {
                    JoinType = JoinType.Domain,
                    Name = domainJoin.Name,
                    Username = domainJoin.Username,
                    Password = domainJoin.Password
                };
            default:
                return null;
        }
    }
}

Answer 2

I think that as a general principle to change the code of your logic to make it easier for your GUI is a code smell.

In general your viewModel will have to do some processing to data to make it suitable for displaying. If that includes dynamically checking it's type, that's perfectly reasonable - it's a fairly common thing to do.

You can throw an exception if an instance of INetWorkJoin is not one of your two types.

In functional programming there's the concept of a Union type, which is perfect for this sort of situation. There are ways to simulate them in C# using internal constructors in an abstract class. However it may not be worth the effort of doing this.

For example

public abstract class NetworkJoin
{
    internal NetworkJoin(){}
    string Name {get;set;}
    void Join();
}

public class DomainJoin : NetworkJoin
{
    public DomainJoin() : base(){}
    string Name {get;set;}
    string Username {get;set;}
    SecureString {get;set;}
    void Join()
    {
        // Domain join code
    }
}

public class WorkgroupJoin : NetworkJoin
{
    public WorkGroupJoin : base(){}
    string Name {get;set;}
    void Join()
    {
        // Workgroup join code
    }
 }

The advantage of this is you can guarantee that noone can implement your base class outside the assembly, so there will only ever be two implementations of the abstract class.

Answer 3

I suggest using composition instead of inheritance.

Bind the DomainJoinVM to a DomainJoinView and the WorkgroupJoinVM to a WorkgroupJoinView. Unite both views in the NetworkJoinView.

                           NetworkJoinView
                           +      +      +
                          /       |       \
            DomainJoinView        |        WorkgroupJoinView
                 +                |                +
                 |                |                |
                 |                |                |
           DomainJoinVM           |         WorkgroupJoinVM
           +             \        |       /               +
           |              +       |      +                | 
IJoinService               NetworkJoinVM                  IJoinService

I also suggest declaring an IJoinService interface to encapsulate and abstract away the Domain Model layer. You then inject it into the view models. This decouples the Domain Model from your View Model, and lets you implement the persistence(serialization) as needed.

Think of it as divide et impera for UI development.

public class NetworkJoinVM
{
    public DomainJoinVM DomainJoin; 
    public WorkgroupJoinVM WorkgroupJoin;
    public JoinType JoinWith;

    public NetworkJoinVM(DomainJoinVm domainJoin, WorkgroupJoinVm workgroupJoin)
    {
        DomainJoin = domainJoin;
        WorkgroupJoin = workgroupJoin;
    }

    public void Join()
    {
        if(JoinWith == JoinType.Domain)
            DomainJoin.Join();
        else
            WorkgroupJoin.Join();
    }
}


public class DomainJoinVM
{
    private IJoinService _joinService; 

    public string DomainName;
    public string UserName;
    public string Password;

    public DomainJoinVM(IJoinService joinService)
    {
        _joinService = joinService;
    }

    public void Join()
    {
        _joinService.DomainJoin(DomainName, UserName, Password);
    }
}


public class WorkgroupJoinVM
{
    private IJoinService _joinService;

    public string Name;

    public WorkgroupJoinVM(IJoinService joinService)
    {
        _joinService = joinService;
    }

    public void Join()
    {
        _joinService.WorkgroupJoin(Name);
    }
}


public enum JoinType
{
    Domain,
    Workgroup
}

You can register the interface implementations in the composition root of your application, and hide the Model details from your ViewModels. This works best using a DI container, but is easy to implement "manually" as well.

public interface IJoinService
{
    void WorkgroupJoin(string workgroup);
    void DomainJoin(string domain, string username, string password);
}

Answer 4

In this case, I would not bind the UI to the model directly. I would have the ViewModel have its own fields for the data.

The big benefit of this is that, if the user changes their selection from "Domain" to "Workgroup" and then back to "Domain", you haven't lost the domain username and password that they entered. But you still get to keep the integrity of your domain-model objects (you never end up with a WorkgroupJoin that has a username in it).

For the data model, I'd follow your Option 2. The viewmodel could take an INetworkJoin in its constructor, and scrape the data from it; and then later, when you're ready to save, you would call a method on the viewmodel (shown here as GetModel) to create a new INetworkJoin with the user-entered data.

public class NetworkJoinViewModel : INotifyPropertyChanged
{
    private JoinType _joinType;
    private string _name;
    private string _domainUserName;
    private string _domainPassword;

    public NetworkJoinViewModel(INetworkJoin join) {
        _name = join.Name;
        if (join is DomainJoin domainJoin) {
            _joinType = JoinType.Domain;
            _domainUserName = domainJoin.Username;
            _domainPassword = domainJoin.Password;
        } else if (join is WorkgroupJoin workgroupJoin) {
            _joinType = JoinType.Workgroup;
            _domainUserName = "";
            _domainPassword = "";
        } else throw new ArgumentException("Unknown INetworkJoin implementation");
    }

    public JoinType JoinType {
        get { return _joinType; }
        set {
            _joinType = value;
            NotifyPropertyChanged(nameof(JoinType));
            NotifyPropertyChanged(nameof(IsUserNameEnabled));
            NotifyPropertyChanged(nameof(IsPasswordEnabled));
        }
    }
    public bool IsUserNameEnabled => _joinType == JoinType.Domain;
    public bool IsPasswordEnabled => _joinType == JoinType.Domain;
    // ... typical INPC implementations of Name, UserName, and Password

    public INetworkJoin GetModel() {
        if (_joinType == JoinType.Domain) {
            return new DomainJoin(Name, DomainUserName, DomainPassword);
        } else if (_joinType == JoinType.Workgroup) {
            return new WorkgroupJoin(Name);
        } else throw new InvalidOperationException("Unknown JoinType");
    }
}