Is it possible to implement the Repository pattern without using entity framework?
I am working on a small dev team of 3 on a small scale (for now) ASP.NET MVC solution. I told my manager that I think that we need a layer of abstraction between our business logic and our controllers. Right now our controllers contain a lot of the business logic that goes on, and other functionality, which I know is bad practice.
I have used the repository pattern in the past at my last position, but I did not implement it there. And I cannot say that I have 100% 'wrapped my head around' the pattern and would know how to implement it on my own. There are so many tutorials out there for this pattern and they all seem to differ usually, even if it is a slight difference.
Another concern of mine is that the other programmer on my team (senior dev) said that we don't need to switch to EF right now. I think because our project is still small, and we don't have the time to make the switch. I respect and understand this so I am wondering if it is possible to still use this pattern without EF.
If so, does anyone have useful tutorials, examples or references?
If not, what should I look to do next? I don't want to show up empty handed. I may just represent our (real world) objects as classes that store and provide functionality. That way there will hopefully be less logic and functionality being performed in the controllers.
Thanks for reading.
Best Answer
Design patterns like the Repository pattern aren't dependent on particular technology, so the obvious answer to your question is "yes, of course you can". You can write repositories which are ultimately backed by any storage technology - the point is that the Repository pattern is a way of structuring your data access code and separating it from your other code. It's described in such a way as to be independent of programming language - provided the language in question has objects and interface inheritance you can make it work.
What it isn't is a way of structuring your business logic and separating it from your view controllers, which is what your explanation actually says you need. For that you've got a number of other options available. Where I work we write a set of Service objects which provide business logic, and the controllers call those (they in turn have Repository objects injected by the DI framework to allow them to access data storage without having to know all the details). Controllers then only contain code which deals with processing incoming data from the UI into a form the services can handle, and turning service responses into something suitable for display to the user.