Question

I currently create a Repository for each database table and a corresponding data class for the column values (object to pass around data).

I recently started using some 1 to 1 relationships and I’m not sure what would be the best way to implement them.

For example

If I have a User table and a UserSettings Table in a 1:1 relationship.

// Data classes (Holds all the field value for the table)
    public class User
    {
        public int UserId { get; set; }
        public string Name { get; set; }       
    } 


     public class UserSettings
        {
            public int UserId { get; set; }
            public bool SomeSetting { get; set; }       
        } 

Questions:

1. Should I always go through the User object to manipulate the UserSettings object, or should I be able to manipulate them
   independently?
2. Should I include the primary key field in the UserSettings object?

3. Should I store a reference to the USerSettings object in the User object?

4. Do I make two repo’s one for User and one UserSettings, or do I handle everything in the Users Repo.

Answer 1

The only time I’ve ever found a 1:1 relationship between aggregate roots to be useful is when the aggregate roots on either side of the relationship are managed by different domains. They must share the same primary key, and therefore if they are both managed by the same domain then they are by definition parts of the same aggregate root. I think you need to approach this question from a different angle:

1. Is the User object only going to exist for this application?
2. Do you expect that to always be the case?

If the User is a concept that resides entirely inside of this domain, then there’s no reason to have a UserSettings aggretate root that has a 1:1 relationship with a User; you simply make User.Settings a way to retrieve the UserSettings for that User. (And of course that obviates the need for a repository – it becomes the responsibility of the UserRepository to hydrate the UserSettings when it hydrates everything else on the User.)

But, if the User will eventually inform sessions for multiple domains, then User needs to represent its own domain, the services of which your application will consume. Then, you gain a very real need to separate the UserSettings of this application from those of a different application. The User is not specific to this application, but the UserSettings for that User is.

NOTE – In the interest of not refactoring your project at this point, if the answer to either question 1 or 2 above is “no”, then you should make UserSettings a separate aggregate root within the same domain, in order to create a seamless transition when you eventually do move User into its own domain.