Должен ли класс обслуживания быть больше чем оболочка класса репозитория?

У меня есть понимание, что использование подпрограмм доступа к данным непосредственно из кода представления считается злом. Поэтому у меня есть отдельный проект Repositories , а также проект Services . Из того, что я могу сказать, типичное использование сервисного уровня - это изоляция доступа к данным из презентации. Все хорошо.

У меня довольно простая область, просто класс Movie . Соответствующий интерфейс репозитория:

public interface IMovieRepository
{
    void AddMovie(Movie movie);
    void UpdateMovie(Movie movie);
    void RemoveMovie(Movie movie);
    int GetMovieCount();
    Movie GetMovieById(int id);
    IEnumerable<Movie> GetAllMovies();
    IEnumerable<Movie> GetMoviesByGenre(Genre genre);
    IEnumerable<Movie> GetMoviesByYear(int year);
    IEnumerable<Movie> GetMoviesByActor(string actor);
    IEnumerable<Movie> GetMoviesByTitle(string title);
}

Теперь, когда я добираюсь до класса обслуживания для использования репозитория, я определяю интерфейс, подобный этому:

public interface IMovieService
{
    Movie CreateMovie(string title, int year, Genre genre, int length, IEnumerable<string> actors);
    void UpdateMovie(Movie movie);
    void RemoveMovie(Movie movie);
    int GetMovieCount();
    Movie GetMovieById(int id);
    IEnumerable<Movie> GetAllMovies();
    IEnumerable<Movie> GetMoviesByGenre(Genre genre);
    IEnumerable<Movie> GetMoviesByYear(int year);
    IEnumerable<Movie> GetMoviesByActor(string actor);
    IEnumerable<Movie> GetMoviesByTitle(string title);
}

Два интерфейса очень похожи, что мне кажется странным. Я ожидаю, что реализация IMovieService будет использовать реализацию IMovieRepository внутри, по существу являясь тонкой оболочкой для последней. Вероятно, может быть какое-то подтверждение или кеширование или тому подобное, но первое кажется, что в большинстве случаев оно просто перейдет ко второму.

Я иду по этому пути правильно, или я что-то упускаю?

Я знаю, что это кажется излишним для такой простой области, но я пытаюсь закрепить схему наслоения и абстракции для использования в будущих и более крупных проектах.

РЕДАКТИРОВАТЬ: чтобы быть немного яснее Я Я не говорю о NHibernate или шаблоне хранилища, а скорее о распределении проблем.

ОБНОВЛЕНИЕ: спасибо, ребята. Я полагаю, что я оставлю конкретные методы запросов в классе обслуживания, чтобы быть простыми для уровня пользовательского интерфейса, и постараюсь обобщить некоторые репозитории, передавая запросы в функцию запроса.