Separate database connection and ORM.

[cxlblm]

In the process of business development, it's common to fetch data through APIs while also desiring to leverage the rich features of an ORM (Object-Relational Mapping) framework. To achieve this, data is often manually initialized as instances of an ORM. However, existing ORM frameworks are tightly coupled with databases. I'm wondering if it's possible to split the ORM into two fundamental classes: one that handles database connections and another that focuses solely on data operations without the need for a database connection. I'm curious to hear what others think about this approach or if there are better suggestions.

[henzeb]

You mean something like this? https://habib-cst.medium.com/laravel-read-write-connections-use-multi-database-2f95d358edb6

There's also https://github.com/calebporzio/sushi, which leverages the power of Eloquent using arrays.

[cxlblm]

The "sushi" library is something I've looked into, but it doesn't quite fit my needs. Perhaps I didn't express what I'm looking for clearly enough. In simple terms, I'd like to use the data mapper pattern to populate all other data into objects. However, the current model holds the database connection by default (in lazy loading mode). I'm wondering if it's possible to split the model into two base classes—one that holds the database connection and another that simply has properties. This would make it easier to choose the appropriate base class at the business layer.

[wizzymore]

Maybe try this: https://spatie.be/docs/laravel-data/v3/introduction
You can use models for the Database fetches and then convert them to Data objects, or use Data objects from any source that you would like.