I have a
WebApi project that uses
Repository Pattern for data layer.
In other projects I have created a Repository by module of by business logic. So instead of having a Repository for each entity I create one Repository that could have inside references to multiple entities because not all entities or db tables will have Updates, Deletes and Inserts.
For example I used to have
EmployeeRepository, and within this repository I would deal anything related to employee so within that repo I can play with many tables that are related of course to an employee.
SQL database has around 350 tables but in this project I just came with the doubt that if the right way to go is to have a Repository for each table or entity, each having its own Add, Get, Remove, Update, Delete, etc.
Considering the above in the
EmployeeRepository example, if for managing employee data I deal with lets say 5 tables:
Then I would have 5 repositories so:
In case the above is the right way to go, is there any plugin that can generate for you the Entity model classes so you dont have to do it one by one by hand?
What is the best practice pattern?
In my opinion there is no best practice for this. It's more driven by the real needs of your project and how these repositories are going to be used.
If you have 350 tables I personally would try to group them into bigger logical repositories. Table structure may change, but the logic behind stays: you want to manage empolyees, and it doesn't matter if you store empolyee data in 1, 2 or 10 tables. Just for the sake of argument, imagine that you have to move to object database and all your empoloyee data is now one document. All your "table"-repositories will have to access one and the same document if you want to keep your business layer without changes.
A guiding rule for me would be "what is my primary entity and what are my dependant entities". Holiday or Leave cannot exist without Employee, so I could imaging an Empolyee repository that says:
GetEmployee(employeeId) GetEmployeeHoliday(employeeId) GetEmployeeLeave(employeeId)
IDs of dependant entities don't really matter here, so a separate repository might be an overkill.
If you decide to go with 350 repositories, I would at least think about generic repository base class that will provide you with generic GetById, Save, Find, etc. methods. Than expand only those repositories that have more logic. I think that would be not more than 50, and those would be more or less your "primary entities" from the first approach.
Anyway, it's all opinionated IMHO and in the end it's up to you, your personal preferences and the needs of your project.