What is the best practice for a service layer design where the business data has a 1 to 0..1 relationship?

Question

Greetings all,

I have researched and found a number of discussions on designing a MVC service layer, but I haven't found an answer to my exact questions. The post on service layer interdependency has an image illustrating what I have in mind, but I have a further question that I don't believe is covered in the referenced post.

My application will track data for a non-profit that interacts with humans in multiple contexts. Maybe the human was a client, maybe they were an adviser, or maybe they were an adversary. They can be multiple. A client may later become an adversary (think lawyers' clients).

My idea is that the creation of a new client or a new adversary always creates two records: 1 record in the person table and one record in the ancillary table. My thoughts behind this is that there will be one place (the person table) to check to see if the business has had any past interaction with a given person.

My question is , when representing entities in a 1 to 0..1 relationship to the controller layer, (1) Should the controller be involved in combining and splitting classes before passing them to a view? (2) If not, should the service layer construct the viewmodel?

I've read the post about the 1800 line Controller here. I've also read this post that says your service layer shouldn't know about the view model, which makes me think it lives and dies in the controller layer. If the service layer doesn't touch the viewmodel, for example, (3) is it good design for the workerService to return both Person and Worker objects to the Controller?

Here are my entity classes:

public class Record
{
    public DateTime datecreated { get; set; }
    public DateTime dateupdated { get; set; }
    public string Createdby { get; set; }
    public string Updatedby { get; set; }
}

public class Person : Record
{   
    public int ID { get; set; }
    public virtual Worker Worker { get; set; }
    publiv virtual Defendant defendant {get; set;}
    ...
}

public class Worker : Record
{
    public int ID { get; set; }
    public virtual Person person { get; set; }
    ...
}

public class Defendant : Record
{
    public int ID { get; set; }
    public virtual Person person { get; set; }
    ...
} 

Answer 1

I think you should try and find a balance between whats "good design" and what works for you.

For instance, I have an MVC application that uses ASP.NET Membership, but I also have a custom User table, where I store things like a user's fiendly name, or OpenID. In that same application I have an IAdminService that handles everything concerning user administration.
What IAdminService returns to the controller is an AdminUser class, which looks like:

public class AdminUser
{
    public string UserName { get; set; }
    public User User { get; set; }
    public MembershipUserWrapper MembershipUser { get; set; }
}

MembershipUserWrapper is just a wrapper around the default MembershipUser to allow for testing and more flexibility in general.

Anyway, you could argue that AdminUser is actually a view model and indeed I do have a couple of views strongly typed to AdminUser. It would be complicating matters unnecessarily to not let IAdminService return an AdminUser just because it is in the "service layer", and in this case, you don't want the controller performing the "transformation" from User and MembershipUserWrapper to AdminUser every time.

is it good design for the workerService to return both Person and Worker objects to the Controller?

I think in this case it probably is. You could have two separate services, but most of the logic for fetching a Worker and a Person is probably the same, so you'd be forcing yourself to either repeat a lot of code or create a third service that performs the common tasks.

You should pay attention to proper desing, but take also K.I.S.S. and YAGNI into account. Do what makes sense now, and refactor accordingly whenever needed.