Hi. I'm just looking for some general guidelines on how I should organize our code. I've traditionally worked with explicit data layers where a specific module would map to a table. With the very "nested" nature of Prisma (where one would create a group of related objects in a single transaction via a nested "create"), it seems like this model of mapping modules to database tables gets very fuzzy. I am curious as to how you all go about invoking Prisma client functions? Does your business logic code invoke the Prisma client directly? In which case, the business logic would have to be very aware of how Prisma works? Do you create an expllicit "data access" layer that tries to encapsulate date queries?

Hey @Alexander Lang 👋 Yes you are correct. Prisma isn’t an ORM so you wouldn’t be able to map modules as you would with TypeORM or Sequelize. In this case you would need to perform nested creates/connects itself for relational data and Prisma handles everything from insertion to optimization under the hood. As for invoking Prisma Client functions, you can directly invoke those in your business logic if you’re using resolvers in GraphQL or Controllers in REST and pass the required data. I personally have never needed an explicit Data Acccess Layer as I did with TypeORM. With Prisma, just a simple call to the DB for querying and updating in your business logic is completely fine. In the end, you can compose and split any logic with functions anyway so that gets managed.

Hey thanks! This helps a lot 😃