That's an application of the Dependency Inversion Principle, part of the SOLID methodology. You always want your code to depend on abstract forms rather than concrete ones. By abstracting database calls into a class, you avoid having to constantly write brittle methods digging deep into concrete implementations.
One way your company's method might evolve is into the Active Record pattern. You define a class around a particular table, implementing domain logic inside that class. You see this pattern used in Rails. If you're using one class per table, I think that's the way it will eventually go.
I like Active Record ORMs for many applications, but only as a persistence layer. Implementing domain logic in a data class is asking for pain, it violates the Single Responsibility Principle. Each class should do only one thing. The thing handling your data persistence should only read/write to the database, it should not also perform calculations or perform actions on anything other than the database.
I refactor domain logic out of models when I see it into Plain Objects with no dependencies, and let the domain have its own abstract world of classes minus ugly database wrappers to play in. I can then write an adapter to the data classes. If it's an existing application in production, then at this point I would start to re-design the database, inevitably it will need work.
I do this by creating another database schema, generating the data classes, simple as pie now without domain logic getting in the way, then create the adapter from examining the existing one. I can then import all the data from the database, represent it as abstract plain objects, then shoot those objects through the other adapter into the new database.
But it only really works if everything does one thing. Your domain objects talk to each other. Your adapter classes go between the domain and the data. The data talks to the database. Achieving this requires hard-won experience with programs that break the principles. You have to feel the pain and recognize where it's coming from. No kata will give you this experience.
Well yes, that's what we do too. The logic implementation is in the Business classes. The data classes just read/write from the tables, and return that data to the business class that performs more meaningful functions on it. This way the data can be used in multiple ways by multiple classes without them depending on each other. A change in domain logic would mean a change in the business class, leaving the data class unaffected
One way your company's method might evolve is into the Active Record pattern. You define a class around a particular table, implementing domain logic inside that class. You see this pattern used in Rails. If you're using one class per table, I think that's the way it will eventually go.
I like Active Record ORMs for many applications, but only as a persistence layer. Implementing domain logic in a data class is asking for pain, it violates the Single Responsibility Principle. Each class should do only one thing. The thing handling your data persistence should only read/write to the database, it should not also perform calculations or perform actions on anything other than the database.
I refactor domain logic out of models when I see it into Plain Objects with no dependencies, and let the domain have its own abstract world of classes minus ugly database wrappers to play in. I can then write an adapter to the data classes. If it's an existing application in production, then at this point I would start to re-design the database, inevitably it will need work.
I do this by creating another database schema, generating the data classes, simple as pie now without domain logic getting in the way, then create the adapter from examining the existing one. I can then import all the data from the database, represent it as abstract plain objects, then shoot those objects through the other adapter into the new database.
But it only really works if everything does one thing. Your domain objects talk to each other. Your adapter classes go between the domain and the data. The data talks to the database. Achieving this requires hard-won experience with programs that break the principles. You have to feel the pain and recognize where it's coming from. No kata will give you this experience.