MVC architecture and custom membershipProvider - asp.net-mvc

Question

Thank you for any thoughts.
I am trying to learn about MVC architecture, and working on a small project which is as much about me learning the tool than the requirements of the project.
I need to figure out what constitutes good, acceptable, and poor practice, and why. I fully understand there will be no specific right answer, but there must be architectures which fit into any of the spectrum of good -> terrible. While in a sense more than a single question, I hope the logical flow of good design practice means they all relate back to a single encapsulating answer.
I m using Code First Membership provider by Darko Pečnik
User implements an interface IUser which hides many of the properties such as Primary key and password, which should be accessed/altered via the methods belonging to Membership class. It also uses a getter and setter for an array of strings rather than the User.Roles Collection via:
public virtual String[] RoleNames
{
set
{
this.Roles = (ICollection<Role>)value.Select(r =>
new Role { RoleName = r }).ToList();
Question 1.) I suspect this property might be bad practice, but am unsure of exactly why. Would these be better as methods GetRoleNames and SetRoleNames, or would the Icollection itself be better included in the IUser interface?
Two seperate viewModels exist which are mapped from IUser using AutoMapper. These models relate to whether the user is registering/updating details about them-self, or being registered/updated by a website administrator.
one viewModel contains an IEnumerable for roles and departments. these properties are currently being mapped via automapper:
internal class RoleStringArrayToSelectListResolver
: ValueResolver<String[], IEnumerable<SelectListItem>>
{
protected override IEnumerable<SelectListItem> ResolveCore(String[] source)
{
return Roles.GetAllRoles().Select(x => new SelectListItem
{
Value = x,
Text = StringExtensions.ToSeparatedWords(x),
Selected = source.Contains(x)
Question 2.) Is autoMapper an acceptable place to put such logic, and if not where should it go?
Question 3.) After postback, business logic is validated via repository methods createUser and updateUser. Would it be optimal for these methods to accept an IUser instance as an argument, or preferable for a couple of overloads accepting the various viewModels as arguments, and if so why?
Thank you very much for any thought ideas and helping my understanding.

Answer 1

Why have you created an IUser interface? I haven't seen any reasons in your question explaining why it is useful. Do you anticipate swapping out different implementations of it? Or does 1 project depend on its properties, without having access to the concrete User class?
Question 1.) I suspect this property might be bad practice, but am
unsure of exactly why. Would these be better as methods GetRoleNames
and SetRoleNames, or would the Icollection itself be better included
in the IUser interface?
It seems to me that what you want to be able to do is access and manipulate Role items in your ICollection Roles property using role name strings only. You could leave the class alone (don't create a property or a method), and just implement this as an extension method:
public static class UserExtensions
{
public static string[] GetRoleNames(this User user)
{
return user.Roles.Select(r => r.Name).ToArray();
}
public static void SetRoleNames(this User user, params string[] roleNames)
{
user.Roles = roleNames.Select(s => new Role { RoleName = s }).ToList();
}
}
With this, you can get and set role names accordingly. The extension method just works against what is already defined in the User class, without cluttering it with overloads. The extension method could just as easily be written against the IUser interface instead of the concrete User class. You would just write this IUser user instead of this User user.
var user = MethodToGetOrCreateUser();
string[] roleNames = user.GetRoleNames();
if (!roleNames.Any())
user.SetRoleNames("StandardUser", "SomeOtherRole");
Question 2.) Is autoMapper an acceptable place to put such logic, and
if not where should it go?
I think I see what you are doing: You have a string[] of role names (probably from your User.GetRoleNames property/method). Given that string array, you want to create an IEnumerable of SelectListItems. There should be a SelectListItem for every role, but only the ones which match a string in your array should be selected. Since your client code does not have all of the Role names, you gave that responsibility to the value resolver. Your client code may then look something like this:
var user = MethodToGetOrCreateUser();
string[] roleNames = user.GetRoleNames();
var rolesMenu = Mapper.Map<IEnumerable<SelectListItem>>(roleNames);
In essence you are making automapper "smart" enough to know how to get all of the other role names that that user is not in. Automapper shouldn't be this smart; having any kind of automapper resolver access a data store is generally not a good idea, and you should avoid it if possible. Otherwise you end up with static references to access data storage. Something like this could go in your controller, and is clearer:
// this should actually go in Application_Start
Mapper.CreateMap<IEnumerable<Role>, IEnumerable<SelectListItem>>()
.ForMember(d => d.Value, o => o.MapFrom(s => s.RoleName))
.ForMember(d => d.Text, o => o.MapFrom(s => s.RoleName.ToSeparatedWords()))
;
// create your menu with all roles
var rolesMenu = Mapper.Map<IEnumerable<SelectListItem>>(Roles.GetAllRoles());
// select only the roles that the user is in
var user = MethodToGetOrCreateUser();
user.GetRoleNames().ToList().ForEach(r =>
{
var match = rolesMenu.SingleOrDefault(i => i.Value == r);
if (match != null) match.Selected = true;
});
I have found that you can avoid ValueResolver classes altogether. Anything you can do with a ValueResolver class you can also do with the lambda overload .ResolveUsing().
Question 3.) After postback, business logic is validated via
repository methods createUser and updateUser. Would it be optimal for
these methods to accept an IUser instance as an argument, or
preferable for a couple of overloads accepting the various viewModels
as arguments, and if so why?
Your business layer should never accept viewmodels as arguments. They are models for the view, not for the business. Think of the business code as your MVC project's client. If you ever moved your business code outside of the MVC project, and you had business code that took ViewModels as arguments, the code would not compile. Why? Because the viewmodels are in the MVC project, and the MVC project takes a dependency on the business project -- not vice versa.