CODEWITHSUNDEEP
sqlasp.net-mvclinq
Dietpixel
Dietpixel

Reputation: 10123

LINQ-to-SQL repository pattern attempt that is working, but am concerned with seperation

I am new to LINQ to SQL and the repository pattern and was attempting to do a simple example to get an understanding of how exactly my application should be structured. On my User model object I have a method called create(). When a user is created I want to insert into my User table and insert into my user_role table to assign the user the lowest possible role. I have a method on User model called create which does all this work. Shown below. Am I on the right path with how the repository pattern with LINQ to SQL should work.

    public Boolean Create()
    {            
        UserDbDataContext context = new UserDbDataContext();

        // Create user.
        IUserRepository userRepo = new UserRepository(context);            
        userRepo.Create(this);

        // Get role that user should be added to.
        IRoleRepository roleRepo = new RoleRepository(context);
        var role = roleRepo.GetByRoleName("rookie");

        // Insert user into role.
        IUserRoleRepository userRoleRepo = new UserRoleRepository(context);
        User_Role userRole = new User_Role();
        userRole.RoleId = role.Id;
        userRole.UserId = this.Id;
        userRoleRepo.Create(userRole);

        context.Dispose();

        return true;
    }

This is my controller method.

    public ActionResult Register(string username, string password, string email)
    {
        User user = new User();
        user.Username = username;
        user.Password = password;
        user.Email = email;
        user.DateCreated = DateTime.Now;
        user.Create();

        return RedirectToAction("Test");
    }

Is there a better approach I could take to improve the process? Any help would be vastly appreciated.

Upvotes: 2

Views: 366

Answers (2)

BrokenGlass
BrokenGlass

Reputation: 160852

One of the main problems in your current approach is that the repositories individually have the responsibility to create/update the entities they hold on the database - This means that if you have changes in one repository and update another repository (i.e. your Create() call) both will be committed to the DB.

The usual way to structure this is having a unit of work (i.e. see here) that sits on top of all repositories that is responsible to commit changes to the DB, this structure also allows for transactions spanning multiple repositories.

Upvotes: 2

Turnkey
Turnkey

Reputation: 9406

I would say you should probably keep the responsibility of the repository to be saving and retrieving data for the entity. The "role" is a bit more on the "business logic" side and I would put that one layer up in a Service so you don't do any business logic responsibilities in the repository. For example you could call it CreateNewUserService and it would take the new users from the repository and then add the role. You would call that directly from the controller passing those arguments that you are applying directly now.

That way if your business logic changes so that you want to intialize the user as something else or not at all, you don't have to rip up the repository as it can keep it's responsibility of providing the user. This keeps the separation of concerns to be more clear as well and helps with maintenance and testability of both the repository and the service.

Upvotes: 1

Related Questions