Your question summary mentioned that your intention is to create DTOs, i.e. Data Transfer Objects, presumably in an API messaging context. Your Employee class can certainly serve this purpose, and might also double as a business object class, with its own business logic, aside from just the auto-properties you've listed.
IIUC, the specialized GetEmployee...
methods will live in a separate factory class, and will create instances of Employee
, with only the required properties populated. I'm guessing you want to do this because your API includes different message contracts with different subsets of Employee properties. GetEmployeeNameEmail
method implementation would look up the Employee with the specified ID, create a new Employee instance, populate only the name and email properties, and return this object.
You can't make the methods private for these different DTO contexts; but you can "hide" them by defining separate interfaces for each property subset. The Employee subclass would implement each of these interfaces:
public interface IEmployeeWithName
{
int EmployeeId { get; set; }
string FirstName { get; set; }
string MiddleName { get; set; }
string LastName { get; set; }
}
interface IEmployeeWithContacts
{
int EmployeeId { get; set; }
string EmailAddress { get; set; }
string HomePhone { get; set; }
string MobilePhone { get; set; }
}
interface IEmployeeWithNameEmail
{
int EmployeeId { get; set; }
string FirstName { get; set; }
string MiddleName { get; set; }
string LastName { get; set; }
string EmailAddress { get; set; }
}
interface IEmployee
{
int EmployeeId { get; set; }
string FirstName { get; set; }
string MiddleName { get; set; }
string LastName { get; set; }
string EmailAddress { get; set; }
string HomePhone { get; set; }
string MobilePhone { get; set; }
}
public class Employee : IEmployee, IEmployeeWithContacts, IEmployeeWithName, IEmployeeWithNameEmail
{
public int EmployeeId { get; set; }
public string FirstName { get; set; }
public string MiddleName { get; set; }
public string LastName { get; set; }
public string EmailAddress { get; set; }
public string HomePhone { get; set; }
public string MobilePhone { get; set; }
}
public class EmployeeFactory
{
private Employee GetEmployeeByID(int id)
{
// this would perform the lookup and populate the Employee object...
return new Employee();
}
public IEmployeeWithName GetEmployeeName(int id)
{
// The return should contain only FirstName, MiddleName and LastName.
return GetEmployeeByID(id);
}
public IEmployeeWithContacts GetEmployeeContacts(int id)
{
// The return should contain only EmailAddress, HomePhone and MobilePhone.
return GetEmployeeByID(id);
}
public IEmployeeWithNameEmail GetEmployeeNameEmail(int id)
{
// The return should contain only FirstName, MiddleName, LastName and EmailAddress.
return GetEmployeeByID(id);
}
public IEmployee GetEmployee(int id)
{
// It should return the entire Employee object
return GetEmployeeByID(id);
}
}
Note that if you pass these to a reflective serializer, your interface facade might not be sufficient to hide properties you want to suppress. In that case, you'd have to go back to creating a new Employee object, but you might be able to leverage something like AutoMapper, in combination with the specialized interfaces, to reduce code redundancy.