#Deep providers? What is the correct approach to take.

6 messages · Page 1 of 1 (latest)

gilded ferry
#

Let's say I have the following:

Groups Module
Users Module
Folders Module
Files Module

Users can belong to groups
Groups can be assigned spaces
Folders can be assigned to a group or user
Files can be assigned to multiple groups/users/folders

Would you create a monolithic module? Would you create additional intermediary modules to extract dependencies?

median mesa
#

@gilded ferry - What is your application doing?

gilded ferry
#

This is a hypothetical example that somewhat mimics the dependency graph of our application.

I'll give one example where things get hairy:

If I delete a folder, I need to delete the files in that folder. But if I want to download a file, it should be prefix the filename with the owner group and folder name. So in essencse, all modules need to know about each other to some extent.

I've thought of either hoisting a separate module up (e.g. DownloadModule) which would then import all other modules so that I can have a more top-down dependency tree. Or combining modules (e.g. groups+users, folders+files). Or perhaps I could do something like leverage request scoped providers to provide session data to leaf modules...for example a request scoped provider could provide the users and their group's metadata to the files services.

#

Maybe circular dependencies are not seen as an issue. But I always thought it was a bit of a design smell.

fresh venture
#

It's a good idea to group modules around "capabilities" rather than "entities"

#

Groups+ users and folders+files sound like a reasonable grouping