Depends: If in your project you want your business layer (BLL) to have no references to data access technologies, data mapping, etc ... of the structure of your project you can use this design pattern . But the implementation of the Repository will not necessarily fall within your business layer (BLL).
Repository isolates domain (business-related) objects from access code details and mapping these objects to the database. That is, it adds a separation layer between the data access and domain layers.
This means that if you have a business layer (BLL) in your application, you can use this design pattern 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've worked a little with Domain Driven Design ( DDD ) and in this scenario if you put your Repository within your business layer, you may end up having technology references (eg 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 using DDD.
In this case we then insert the Interface (s) of the repository (s) into the business layer, letting the infrastructure layer deploy the repository interfaces and this layer does have reference to the technologies used for recovery, persistence of data, etc.