2 Elaborated based on a comment.
source | link

You do not need one repository per table. A repository can encapsulate all data access required for a given entity. The record in the users table is associated with a record in the user types table by way of a foreign key. You can model this in C# as well by replacing the User.FK_UserType property with an actual UserType object. The UserRepositoryDal (which "UserRepository" is descriptive enough that you can drop the "Dal" suffix") can query the database appropriately using a JOIN:

SELECT users.a, users.b, userTypes.a, userTypes.b
FROM t_users users
    JOIN t_user_types ON ...

When you need to reuse database mappings from tables to objects, create a new class in C# just for the data mapping.

No need for a separate repository.


Ok - let's say now i want to populate combobox with all UserTypes names and values as id to be taken later on when user selects something from that control. Where GetAll for UserType should be defined? in UserRepository as well?

This is honestly a good question, and one I have as well. Laiv mentioned adding a "lookup" which could be its own "repository" or data access class that specializes in generating the data for things like combo boxes. You can also add a GetUserTypes() method or a UserTypes property to the UserRepository that returns a collection of UserType objects, which you can use later on to create a new collection of combo box items.

I've used a property on the repository for lookup entities. Transforming them into combo box items is usually pretty easy:

var comboBoxItems = from userType in userRepository.UserTypes
                    select new SelectListItem()
                    {
                        Text = userType.Name,
                        Value = userType.Id.ToString()
                    };

You do not need one repository per table. A repository can encapsulate all data access required for a given entity. The record in the users table is associated with a record in the user types table by way of a foreign key. You can model this in C# as well by replacing the User.FK_UserType property with an actual UserType object. The UserRepositoryDal (which "UserRepository" is descriptive enough that you can drop the "Dal" suffix") can query the database appropriately using a JOIN:

SELECT users.a, users.b, userTypes.a, userTypes.b
FROM t_users users
    JOIN t_user_types ON ...

When you need to reuse database mappings from tables to objects, create a new class in C# just for the data mapping.

No need for a separate repository.

You do not need one repository per table. A repository can encapsulate all data access required for a given entity. The record in the users table is associated with a record in the user types table by way of a foreign key. You can model this in C# as well by replacing the User.FK_UserType property with an actual UserType object. The UserRepositoryDal (which "UserRepository" is descriptive enough that you can drop the "Dal" suffix") can query the database appropriately using a JOIN:

SELECT users.a, users.b, userTypes.a, userTypes.b
FROM t_users users
    JOIN t_user_types ON ...

When you need to reuse database mappings from tables to objects, create a new class in C# just for the data mapping.

No need for a separate repository.


Ok - let's say now i want to populate combobox with all UserTypes names and values as id to be taken later on when user selects something from that control. Where GetAll for UserType should be defined? in UserRepository as well?

This is honestly a good question, and one I have as well. Laiv mentioned adding a "lookup" which could be its own "repository" or data access class that specializes in generating the data for things like combo boxes. You can also add a GetUserTypes() method or a UserTypes property to the UserRepository that returns a collection of UserType objects, which you can use later on to create a new collection of combo box items.

I've used a property on the repository for lookup entities. Transforming them into combo box items is usually pretty easy:

var comboBoxItems = from userType in userRepository.UserTypes
                    select new SelectListItem()
                    {
                        Text = userType.Name,
                        Value = userType.Id.ToString()
                    };
1
source | link

You do not need one repository per table. A repository can encapsulate all data access required for a given entity. The record in the users table is associated with a record in the user types table by way of a foreign key. You can model this in C# as well by replacing the User.FK_UserType property with an actual UserType object. The UserRepositoryDal (which "UserRepository" is descriptive enough that you can drop the "Dal" suffix") can query the database appropriately using a JOIN:

SELECT users.a, users.b, userTypes.a, userTypes.b
FROM t_users users
    JOIN t_user_types ON ...

When you need to reuse database mappings from tables to objects, create a new class in C# just for the data mapping.

No need for a separate repository.