I have a project with ASP.NET MVC, using Entity Framework to get data from SQL database.
I designed data classes, which hold information such as Statistics (Class combined a product ID, its entries, which is a subclass), and then I realized, to put data in these classes, I would have to have a set of functions, to retrieve the data from SQL, and put to the data classes.
Then I found the repository method, and I wanted to ask, is it just a set of functions, which keeps the business logic in one place? Or is it more complex then that? I have a interface for it, and then the implementation.
The idea of a repository is to give your code one place they can go too to fetch data from some persistent store (most of the time your database). Your business logic would be in another layer.
The repository can offer simple Create, Read, Update and Delete (CRUD) functions or more specific ones for fetching or updating data.
Other patterns you can look at are UnitOfWork (the ObjectContext used in the Entity Framework is an example of this) and the Layering design patterns which show you how to seperate the data access code from your business code.
You already mentioned separating the interface from the implementation. Coding to an interface is also a good practice.
Here you can find some more information. PEAA also contains other great descriptions of design patterns and how to use them.