Is it good practice creating two or three basic interface repository for a single project for example , I want to keep IDatRepositorforCustomer, IDataRepositoryforEmployee
It depends on usage and readability. It have advantages like separation of concerns, ease of maintenance, distribution of work between multiple teams, single responsibility etc..
Let suppose you have two controller, one for dealing with Account only and you have one Account Repository then its good to inject the relevant repository in controller, if you need some thing from business then you can inject it otherwise if don't need,don't
inject that give freedom.
You can optimize multiple repositories for using single connection and use unit of work for single transaction.
We cannot solve our problems with the same thinking we used when we created them.
Is it good practice creating two or three basic interface repository for a single project for example , I want to keep IDatRepositorforCustomer, IDataRepositoryforEmployee
A repository should be based on business needs, like Inventory, Customer, Address, Sales, etc. and etc. However, a repositroy object is a domain object and not a data access/data persistence object.
You should think of a repository as a collection of domain objects in memory. If you’re building an application called Vega, you shouldn’t have a repository like the following:
public class VegaRepository
{
}
Instead, you should have a separate repository per domain class, like OrderRepository, ShippingRepository and ProductRepository.
I have nothing against the repository pattern, if used properly as a domain solution and not a data access/data persistence solution. And I avoid the generic repository pattern that is too generic like it's a plague.
If you find the post has answered your issue, then please mark post as 'answered'.
Member
299 Points
1033 Posts
create two basic repository interface in a single project
Nov 02, 2019 07:58 PM|polachan|LINK
Hi
Is it good practice creating two or three basic interface repository for a single project for example , I want to keep IDatRepositorforCustomer, IDataRepositoryforEmployee
Please I am looking for the advise from expertise
Pol
Contributor
2016 Points
1024 Posts
Re: create two basic repository interface in a single project
Nov 02, 2019 08:22 PM|Khuram.Shahzad|LINK
It depends on usage and readability. It have advantages like separation of concerns, ease of maintenance, distribution of work between multiple teams, single responsibility etc..
Let suppose you have two controller, one for dealing with Account only and you have one Account Repository then its good to inject the relevant repository in controller, if you need some thing from business then you can inject it otherwise if don't need,don't inject that give freedom.
You can optimize multiple repositories for using single connection and use unit of work for single transaction.
Contributor
4101 Points
3465 Posts
Re: create two basic repository interface in a single project
Nov 02, 2019 08:47 PM|DA924|LINK
Is it good practice creating two or three basic interface repository for a single project for example , I want to keep IDatRepositorforCustomer, IDataRepositoryforEmployee
A repository should be based on business needs, like Inventory, Customer, Address, Sales, etc. and etc. However, a repositroy object is a domain object and not a data access/data persistence object.
https://martinfowler.com/eaaCatalog/repository.html
https://programmingwithmosh.com/net/common-mistakes-with-the-repository-pattern/
<copied>
You should think of a repository as a collection of domain objects in memory. If you’re building an application called Vega, you shouldn’t have a repository like the following:
public class VegaRepository
{
}
Instead, you should have a separate repository per domain class, like OrderRepository, ShippingRepository and ProductRepository.
<end>
https://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework-core/
EF already implements the repository pattern so to have a repository over a repository in a data access/data persistence manner is not optimal.
http://hamidmosalla.com/2018/11/25/stop-using-repository-pattern-with-an-orm/
I have nothing against the repository pattern, if used properly as a domain solution and not a data access/data persistence solution. And I avoid the generic repository pattern that is too generic like it's a plague.