Using NerdDinner as base reference, how to perform data access tasks in controller?

Question

I am trying to follow the Nerd Dinner MVC application as a base to learn the correct way to develop MVC applications.

I have created Interfaces and Repositories as the reference code suggests and am using Entity Framework for data access.

If I want to insert data when a user registers into a table [dbo].[Users], I do not have a controller for Users, how do I do it?

AccountController.cs

[HandleError]
public class AccountController : BaseController
{
    [HttpPost]
    public ActionResult Register(RegisterModel model)
    {
        if (ModelState.IsValid)
        {
            // Attempt to register the user
            MembershipCreateStatus createStatus = MembershipService.CreateUser(model.UserName, model.Password, model.Email);

            if (createStatus == MembershipCreateStatus.Success)
            {
                // TODO: Enter record into [Users] get reference to [Aspnet_UserId]
                // How do I do this??



                //FormsService.SignIn(model.UserName, false /* createPersistentCookie */);
                return RedirectToAction("Index", "Home");
            }
            else
            {
                ModelState.AddModelError("", ErrorCodeToString(createStatus));
            }
        }

        // If we got this far, something failed, redisplay form
        return View(model);
    }
}

If I create a UsersController to display views based on the Users table, how would I then add a new record when the user is registering?

I have a separate table [Users] that I wish to populate when a new user registers adding the [Aspnet_UserId] Guid.

Answer 1

You don't need to have a controller for each table in your database. In the code above, the MembershipService is the code that is actually creating the record (via the Repository for users).

The controllers should represent various areas and groups of functionality your website provides. While in many cases, you might have a controller with View, Create, and Update actions that do relate to a specific entity, that does relate to a specific database table, that isn't and shouldn't always be the case.

If it makes sense to have a UsersController because you want to view a list of users, or a specific users profile, that's fine, but the form for creating a user doesn't have to be a part of that controller. Having it be a part of a membership, or admin, or account, or registration controller is ok too.

Update I'll try to provide you sample code of how I would expect the code to look. But you might have something else in mind, which is fine too, there's no true single way to do these things.

In your code above, I'm not sure what your MembershipService class is doing. It appears there is a static method on it that does something related to User Creation. I would expect that your MembershipService class should be calling your UserRepository to actually do the user creation. But you probably wouldn't want a static class/method for this.

public class MembershipCreationResult
{
  public User Member { get; private set; }
  public MembershipCreateStatus MembershipCreateStatus { get; private set; }

  public MembershipCreationResult(User user, MembershipCreateStatus status)
  {
    Member = user;
    MembershipCreateStatus = status;
  }

  public bool Success
  {
    get { return MembershipCreateStatus == MembershipCreateStatus.Success; }
  }
}

public class MembershipService
{
  public IUserRepository { get; private set; }

  public MembershipService(IUserRepository userRepository)
  {
    UserRepository = userRepository;
  }

  public MembershipCreateResult CreateUser(string name, string password, string email)
  {
    User member = UserRepository.Create(name, password, email);
    bool status = member != null ? MembershipCreateStatus.Success : MembershipCreateStatus.Failure;

    return new MembershipCreationResult(status, member)
  }
}

I haven't taken a very close look at the NerdDinner sample, and I haven't used the ASP.NET membership provider, but the concept I have outlined above should work. If MembershipService does something way different from what I have outlined, then you could create a new service to wrap the functionality and leave the existing MembershipService alone.