Repository pattern implementation advice

Question

I'm implementing the repository pattern on an existing system, predominantly in order to be able to unit test my business logic layer in isolation. But i've concerned I have a layer too many, and advice would be greatly appreciated. There is no ORM in place, SQL Server is used as the database.

I have the following:

1. DataMapping Layer - linking objects to database tables
2. Repository Interface
3. Repository Concrete Implementation
4. Business Logic Layer
5. Presentation Layer

I find that I am often creating a method in the Repository Concrete Implementation which is returning a simple piece of data (an Expiry Date - DateTime variable for example), then putting together a Business Logic Layer method that is running the Repository Concrete Implementation method and returning it to the Presentation Layer.

Is there a case for the Presentation Later calling the Concrete Implementation method direct if the BLL is not adding in any additional logic? And only using a BLL method if there is additional logic to Unit Test?

I am using dependency injection to manage the Concrete Impementation.

Thanks.

Answer 1

Sounds to me like you are misunderstanding the purpose of the Repository pattern. The idea is to create a class which allows you to centrally manage all storage/retrieval of a particular model - using it to return simple types like DateTime seems like the wrong approach.

Your repository should be dealing purely with objects, so you would have methods like

SomeClass GetSomeClass(...);
void AddSomeClass(...);

Not

DateTime GetExpiryDate(...);
string GetName(...);

The point of a layered architecture is to make sure you don't couple the various parts of your application

• DAL should not know about BLL/PL
• BLL should know about DAL, but should be controlled via your Repositories
• PL should know about the BL but should be controlled via Services (usually)

It's generally considered a good idea to work with interfaces rather than concrete classes when communicating between layers. An interface defines a contract which you can then model your respective layer around - the idea being you are hiding the implementation therefore if you completely changed it in the future the other layers wouldn't know.

For example, if your BLL communicates with the DAL via an IRepository interface, the BLL can only work within the confines of that interface, it has no idea what sort of storage mechanism the DAL is using - this is known as persistence ignorance. So if in the future you swapped out the DAL from a MS SQL backend to a MySQL backend this would have no effect on your BLL because the contract between the layers (i.e. the IRepository interface) hasn't changed.

Answer 2

using repository pattern does not depend on if you are using an ORM or not, you can simply use classical Ado.net in repository base. but about layering your application I advice you to take a look at this blog post

Is there a case for the Presentation Later calling the Concrete Implementation method direct if the BLL is not adding in any additional logic? sure if you don't have any BLL or service layer imp, you can directly call repository in your presentation later.

refer to this article to implement repository correctly