design-patterns - 服务类是否应该不仅仅是存储库类的包装器？

Question

我的理解是，直接从演示代码中使用数据访问例程被认为是邪恶的。所以我有一个单独的Repositories项目，以及 Services项目。据我所知，服务层的典型用途是将数据访问与表示隔离开来。一切都很好。

我有一个非常简单的域，只是一个 Movie类(class)。匹配的存储库接口(interface)是:

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);
}

现在，当我使用服务类来使用存储库时，我最终定义了一个这样的接口(interface):

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 或存储库模式，而是关于关注点的分层。

更新:谢谢大家。我相信我会在服务类上保留特定的查询方法，以使 UI 层更直观，并尝试通过将查询传递给查询函数来概括存储库。

Answer 1

我认为你是正确的。您的 DataAccess API 和 ServiceAPI 看起来如此相似的原因是您还没有为您的服务提供任何真正的业务逻辑。这里有一些可能最终出现在您的服务 API 上的事情的头脑 Storm ，但会涉及一些比简单的 CRUD(创建、读取、更新、删除)功能更复杂的操作。显然这些只是快速而肮脏的例子，但我相信你明白了:

RecommendMovieToFriend(int movieID, stringfriendEmail);

RateMovie(int movieID, int numberOfStars);

AddMovieToMyWishList(int movieID, int userID);

我认为 ServiceLayer 和 DataLayer 的分离是一个重要且有值(value)的分离，你不应该怀疑它，即使这两个 API 目前非常相似。随着服务功能的增长，这两个 API 将继续发散，以满足调用者的需求。