Depends: If in your project you want your business layer (BLL) not to have references to data access technologies, data mapping, etc... of your project structure you can use this Pattern design. But the implementation of Repository will not necessarily stay within your business layer (BLL).
Repository isolates domain objects (business-related) from access code details and mapping those objects with the database. That is, it adds a layer of separation between the data and domain access layers.
This means that if you have a business layer (BLL) in your application, you can use this Pattern design to have a clear separation between your data access layers and your business layer.
Por que ter essa separação e cenário onde utilizei:
I worked a little with Domain Driven Design (DDD) and in that scenario if you put your Repository within your business layer, you may end up having references to technologies (example Nhibernate, Entity, etc.), which is not recommended (since business rules have no relation to the technologies used in the project, the idea here is you do not mix these two things) when DDD is used.
In that case then we insert a(s) Interface(s) do(s) repository(s) in the business layer, leaving the infrastructure layer to implement the repository interfaces, and this layer does refer to the technologies used for recovery, data persistence, etc.
Then serial Classbll -> Classrepository -> Classdal. Repository would be an intermediary of DAL, Dal would have data access(Insert,delete, update,select) which would pass to Repository which could have other gets (getClienteBy algumacoisa) and BLL would do the validation itself and the business rule "to add order, link products with customer, blabala" That?
– Rod