Difference between Repository and Service Layer?

Question

Repository Layer gives you additional level of abstraction over data access. Instead of writing

var context = new DatabaseContext();
return CreateObjectQuery<Type>().Where(t => t.ID == param).First();

to get a single item from database, you use repository interface

public interface IRepository<T>
{
    IQueryable<T> List();
    bool Create(T item);
    bool Delete(int id);
    T Get(int id);
    bool SaveChanges();
}

and call Get(id). Repository layer exposes basic CRUD operations.

Service layer exposes business logic, which uses repository. Example service could look like:

public interface IUserService
{
    User GetByUserName(string userName);
    string GetUserNameByEmail(string email);
    bool EditBasicUserData(User user);
    User GetUserByID(int id);
    bool DeleteUser(int id);
    IQueryable<User> ListUsers();
    bool ChangePassword(string userName, string newPassword);
    bool SendPasswordReminder(string userName);
    bool RegisterNewUser(RegisterNewUserModel model);
}

While List() method of repository returns all users, ListUsers() of IUserService could return only ones, user has access to.

In ASP.NET MVC + EF + SQL SERVER, I have this flow of communication:

Views <- Controllers -> Service layer -> Repository layer -> EF -> SQL Server

Service layer -> Repository layer -> EF This part operates on models.

Views <- Controllers -> Service layer This part operates on view models.

EDIT:

Example of flow for /Orders/ByClient/5 (we want to see order for specific client):

public class OrderController
{
    private IOrderService _orderService;

    public OrderController(IOrderService orderService)
    {
        _orderService = orderService; // injected by IOC container
    }

    public ActionResult ByClient(int id)
    {
        var model = _orderService.GetByClient(id);
        return View(model); 
    }
}

This is interface for order service:

public interface IOrderService
{
    OrdersByClientViewModel GetByClient(int id);
}

This interface returns view model:

public class OrdersByClientViewModel
{
     CientViewModel Client { get; set; } //instead of ClientView, in simple project EF Client class could be used
     IEnumerable<OrderViewModel> Orders { get; set; }
}

This is interface implementation. It uses model classes and repository to create view model:

public class OrderService : IOrderService
{
     IRepository<Client> _clientRepository;
     public OrderService(IRepository<Client> clientRepository)
     {
         _clientRepository = clientRepository; //injected
     }

     public OrdersByClientViewModel GetByClient(int id)
     {
         return _clientRepository.Get(id).Select(c => 
             new OrdersByClientViewModel 
             {
                 Cient = new ClientViewModel { ...init with values from c...}
                 Orders = c.Orders.Select(o => new OrderViewModel { ...init with values from o...}     
             }
         );
     }
}

As Carnotaurus said the repository is responsible for mapping your data from the storage format to you business objects. It should handle both how to read and write data(delete, update too) from and to the storage.

The purpose of service layer on the other hand is to encapsulate business logic into a single place to promote code reuse and separations of concerns. What this typically means for me in practice when building Asp.net MVC sites is that I have this structure

[Controller] calls [Service(s)] who calls [repository(ies)]

One principle I have found useful is to keep logic to a minimum in controllers and repositories.

In controllers it is because it helps keeping me DRY. It's very common that I need to use the same filtering or logic somewhere else and if I placed it in the controller I can't reuse it.

In repositories it is because I want to be able to replace my storage(or ORM) when something better comes along. And if I have logic in the repository I need to rewrite this logic when I change the repository. If my repository only returns IQueryable and the service does the filtering on the other hand, I will only need to replace the mappings.

For example I recently replaced several of my Linq-To-Sql repositories with EF4 and those where I had stayed true to this principle could replaced in a matter of minutes. Where I had some logic it was a matter of hours instead.

The accepted answer (and upvoted hundreds of time) has a major flaw. I wanted to point this out in the comment but it will just get buried down there in 30 something comments so pointing out here.

I took over an enterprise application which was built that way and my initial reaction was WTH? ViewModels in service layer? I did not want to change the convention because years of development had gone into it so I continued with returning ViewModels. Boy it turned into a nightmare when we started using WPF. We (the team of devs) were always saying: which ViewModel? The real one (the one we wrote for the WPF) or the services one? They were written for a web application and even had IsReadOnly flag to disable edit in the UI. Major, major flaw and all because of one word: ViewModel!!

Before you make the same mistake, here are some more reasons in addition to my story above:

Returning a ViewModel from the service layer is a huge no no. That's like saying:

1. If you want to use these services you better be using MVVM and here is the ViewModel you need to use. Ouch!

2. The services are making the assumption they will be displayed in a UI somewhere. What if it is used by a non UI application such as web services or windows services?

3. That is not even a real ViewModel. A real ViewModel has observability, commands etc. That is just a POCO with a bad name. (See my story above for why names matter.)

4. The consuming application better be a presentation layer (ViewModels are used by this layer) and it better understand C#. Another Ouch!

Please, don't do that!

Usually a repository is used as scaffolding to populate your entities - a service layer would go out and source a request. It is likely that you would put a repository under your service layer.