In a system I'm working on there is a core User table. There are also roles designating various user types and application level access.
To keep the user table succinct, there is going to be a number of tables (or possibly just 1 table) holding the extra fields needed for each user type Profile.
Rather than have a number of methods returning each Profile type, would there be any issue with returning an ExpandoObject from the ProfileService? This would allow a simple FetchProfile(foo userType)
function.
e.g:
public ExpandoObject FetchProfile(UserType userType)
{
dynamic x = new ExpandoObject();
switch(stuff)
{
case UserType .Type1:
//The ExpandoObject will be pulled from DB using Dapper.Net
return x;
case UserType .Type2:
//The ExpandoObject will be pulled from DB using Dapper.Net
return x;
default:
return null;
}
}
This ProfileService will be used in multiple levels of the framework (n tier.)
Are there any issues with doing this? Or would it be better to use single classes for each profile type and perhaps use generics to pull out the needed Profile class:
public T FetchProfile<T>(UserType userType) where T : IProfileObject ...
The advantage of the ExpandoObject is that the database could be constructed in such a way that new ProfileTypes can be added when the site is live without needing to add extra ProfileType classes.