3

I have an application with dependency injection that consumes a REST API. The API calls are abstracted into entity-specific repositories. Some of the repositories are: HttpNotebookRepository, HttpPageRepository, HttpBookmarkRepository, HttpUserRepository and their corresponding interfaces.

I have a NotebookHierarchyController which requires four of these repositories via constructor injection:

// constructor
public NotebookHierarchyController(
    NotebookRepository notebookRepo, 
    PageRepository pageRepo, 
    BookmarkRepository bookmarkRepo, 
    UserRepository userRepo, <other dependencies>
) { .. }

There a multiple such controllers requiring more than one or two repositories. I have been planning to create a composite repository as follows:

public class CompositeRepository {
    private NotebookRepository notebooks;
    private PageRepository pages;
    private BookmarkRepository bookmarks;
    private UserRepository users;
public CompositeRepository(NotebookRepository notebooks, 
    PageRepository pages, 
    BookmarkRepository bookmarks, 
    UserRepository users) {
    // assign to fields
}

public NotebookRepository notebooks() {
   return notebooks;
}

public PageRepository pages() {
   return pages;
}

public BookmarkRepository bookmarks() {
   return bookmarks;
} 

public UserRepository users() {
   return users;
}

}

And then inject it into my controller:

// constructor
public NotebookHierarchyController(CompositeRepository repo) { .. }

I now easily have access to all repositories:

repo.notebooks().updateName(..);
repo.sections().add(..);
...

I have people do this in some implementations of the Unit of Work Pattern. However, as far as I understand, the goals of a unit of work are different. It is primarily for transaction coordination. This may also be different from wrapping the repository in a service to add business logic and decoupling.

What I've done is a simple grouping of repositories into one service for convenience. Is this an anti-pattern? Or should I prefer individually injecting each repository? Or is there a more accepted and standard way to deal with this?

Amal K
  • 111

1 Answers1

1

You are doing fine. What you have created is a simple Facade service. It is a standard way of reducing a growing number of constructor parameters (see this older SE.SE answer here).

The only thing which is debatable is the class name. CompositeRepository sounds very generic for a facade specialized for a NotebookHierarchyController. I personally would prefer a more specialized name like NotebookHierarchyRepoService (but YMMV).

Doc Brown
  • 218,378