#Correct usage of services/TypeORM repositories

13 messages · Page 1 of 1 (latest)

fallow island
#

Hi, this is more of a general question related to OOP / multiple frameworks.

Suppose I have module A and module B. Module A is tied to cinemas.
Module B is tied to movies.

Both modules have one service. Both cinema and movie have their TypeORM entity and TypeORM repository.

Now, suppose inside the movie service, you need to get data from a specific cinema.

Would you inject TypeORM repository or would you inject cinema service that looks up the specific cinema?

From my point of view, I would inject the repository itself and would do the specific find in the method in the movie service itself.

Injecting the cinema service calling the method there implemented that is basically a wrapper over the repository itself, would create a tight coupling between the services, and would just complicate things.

What's your take? Thanks

upper yew
#

i think a better approach would be to use the service instead of the repository, using typeorm repository directly will actually increase your coupling between modules

#

instead of looking up where you are doing searches of cinemas and fixing those endpoint one by one it's simplier to just do the requirement on the service

#

keep in mind theres always going to be "coupling", but that article from scott its great to keep that coupling low

#

i'm not the most experienced but i hope this help you a bit

fallow island
#

Hi, thanks!

I read this article before, and it does not quite answer my question. You said you would inject a service instead, as repository would create more coupling.

My point is, suppose you do this:

@Module({
  imports: [TypeOrmModule.forFeature([Cinema])],

and

constructor(
    @InjectRepository(Cinema)
    private cinemaRepository: Repository<Cinema>,
  ) {}

Doing this actually imports the global TypeORM module and not the repository itself. And importing the TypeORM module, which is considered global, should not create more coupling between modules.

lapis swan
#

How about introducing another service that uses both? I wonder what scenario you have in mind. Please be specific!

You probably feel like a cyclic graph is inevitable. If so, then it's a modeling problem, not NestJS's.

fallow island
#

Well, introducing another module that uses both is a valid use case when there is a potentional circular reference. But that is not what I'm trying to discuss.

The simple scenario is whether it is better to import a cinema module that has a service containing findOne method to retrieve the cinema (the service calls the cinema repository), or to import a TypeOrmModule.forFeaure([Cinema]) and call this.cinemaRepository.findOne directly

#

One creates a relationship between:

  1. cinema and movies module
  2. cinema and TypeORM module

It requires more code, fails when there is a need to return a DTO from the findOne method in cinema service as the movies service may need the raw entity itself

The other one creates a relationship between

  1. movies and TypeORM module

Requires less code

spark dragon
#

i think it's best to follow a parent child relation
where movies are part of a cinema this is imo the most logical approach

i agree with the injecting a repository over a service here as things should be kept too them self
any cinema functionality should be implanted in to the cinema service and same story for movie

uncut horizon
#

I've tried both but recently I'm mostly importing repositories. with deeply nested objects it's easier to control what relations I need filled and often times I just need the object from the repository and not any additional logic from the service.

upper yew
#

@fallow island maybe if you provide how you have structured your relation map we can give you a better response