Is hooking Data access method on wrong object detrimental for a developer

Question

In a simple application I am creating there are Admin and users where admin can create users. Right now I am creating Classes that encapsulate database CRUD calls with methods.

For example: adminStore.CreateUser(userObject)

will persist that user object into the Database and return the object. I am now confused as to which DataAccess entity I need to attach methods like these. Doing them on adminStore will make them sensible in sense developer would understand that admin is creating the user and has access role. But from another perspective the below to sounds logical.

like: userStore.CreateUser(userObject);.

So my questions would somewhat sound like a Api design,Class design question but I would like to know which if the below is the right one.

1 UserStore.CreateUser(userObject)

2 AdminStore.CreateUser(userObject)

Update: Here is what i came up with later after viewing the answers.

User { Name ,Email, Password }

Admin:User,IImplementsAdmin { FlagPost() etc etc }

AdminStore { CreateUser(), SetUserStatus() }

Answer 1

Doing them on adminStore will make them sensible in sense developer would understand that admin is creating the user and has access role.

The business policy has little to do with these design decisions. Policies change frequently. Just avoid creating circular dependencies and it will work out. For example, if createUser calls methods in AdminStore, and AdminStore is already dependent on UserStore, then put the method in AdminStore. If createUser has no dependency on AdminStore, or if UserStore already depends on AdminStore, then put the method in UserStore.

I have found that writing the code test-first leads me to a workable design almost automatically. If I wrote a unit test for createUser, and didn't need to instantiate AdminStore to define the test, that would be a strong sign that the createUser belongs in UserStore and not AdminStore.

Don't dwell too long on these little design decisions. Just pick one, and get back to work. Later you may see that it would be better the other way. No problem. It's just code. Change it.

When you see a beautifully designed application or library, it is almost certainly the result of a lot of refactoring, and not the result of some brilliant initial design.

Answer 2

I am not sure about your object model, but I would create a user class and an 2 other classes inheriting from user. One class would be the admin class and the other is the regular user class. A method like CreateUser would be the responsibility of the admin class that inherits from the user class. Optionally, you could choose to make the super user class an abstract class.

A side note: You need to consider here what if an admin becomes a regular user and what if regular user becomes an admin? Your model should accommodate for this.