Class Design and Separation Of Concerns

Question

I'm working on an MVC application and am wondering about the best way to design one of my models.

I have a class called RightLeftPersonToggle which represents two select list boxes on the page. The user is able to move "persons" between the left and right box using buttons between them.

This class can represent both a vehicle driver or manager so the load and save code is different for each type. The class is below.

public class RightLeftPersonToggle
{
    public RightLeftPersonToggle()
    {
        LeftList = new List<Person>();
        RightList = new List<Person>();
    }

    public List<Person> LeftList { get; set; }
    public List<Person> RightList { get; set; }
    public string LeftListTitle { get; set; }
    public string RightListTitle { get; set; }
    public string PropertyName { get; set; }
}

I'm wondering what the best way to handle the loading and saving of the lists is. I've come up with two solutions but I'm not sure on which one is best.

1) The controller (or parent model) is responsible for loading and saving both LeftList and RightList. The RightLeftPersonToggle class has no knowledge of that code and remains exactly like the code above.

2) RightLeftPersonToggle gets two methods (one for save and one for load) which take functions as parameters to tell it how to do its job.

public void LoadAndFilterLists(Func<List<Person>> leftListFilter, Func<List<Person>> rightListFilter)

public void LoadSaveLists(Func<List<Person>> leftListSave, Func<List<Person>> rightListSave)

Solution number one keeps the code more simple in my opinion while solution number two seems to provide better sepration of concerns since RightLeftPersonToggle should know how to load and save itself.

Keeping in mind the fact that RightLeftPersonToggle doesn't always load and save data the same way, which of my proposed solutions would be considered best practice? Do you have any other recommendations for improvement?

Answer 1

If the logic needed to save the data differs depending on what's being shown in the lists, you should have the controller handle saving the lists. The code you've shown seems to be for your view, so all it should worry about is displaying the lists and shouldn't need to know what's actually in them. Let the controller figure out what type of data is in the 2 lists and what the appropriate save logic would be.

Answer 2

In a more general sense, I would have my business classes represent the real-world relationships. When a non-technical person is speaking about a Person, are they really talking about a Person's LeftList and RightList? Or is this more of a hierarchical relationship?

The use of list boxes and such is a UI concern. Your UI will be responsible for taking the set of list boxes and other input elements and mapping them over to objects that the domain model can work with.

Personally, I try to avoid exposing my domain model to my UI so I use a service layer that handles mapping between my entities and the DTOs that my UI works with. The service layer also makes calls to the repository and I strive to keep all of my business logic in my entities.

The ASP.NET MVC UI takes the DTOs and maps them to view models and the views are strongly typed to view-specific view models. The view models have awareness of UI components like SelectList but not the DTOs or entities. The controllers are as thin as possible and coordinate service calls and returning views/redirects.

Answer 3

I have two ideas, one that I've struck off and the second which I favour.

1. My non-favoured idea: Why not create two sub classes of RightLeftPersonToggle, one for VehicleDriver and one for Manager, and implementing the Save/Load functionality in those subclasses? Your Parent class is responsible for creating the right type of class based on what kind of objects it is dealing with.

2. My second idea is to have your RightLeftPersonToggle class accept something like an IPersonRepository in the constructor, and call _personRepository.Save and _personRepository.Load from within the RightLeftPersonToggle class. It keeps the code separate, but still allows it to be called from the object repsonsible for it.