Split Business Logic from Database work

Hi Guys, I'm wondering how to implement and idea I've been kicking around.

I've come from a background using ActiveRecord patterns to create models that both
1) Store buiness logic
2) Save to the database

Generally speaking, I've seen the general idea referred to as

Datamapper
Domain Models
Datamapper + Domain Models

Even the repository pattern is vaguely related.

But my goal is to split business logic from the database implementaiton. Basically I've come to conclude that a Model != Table!

Consider a shopping cart as an example. It contains a list of products to purchase for a particular user. I'd like to represent the shopping cart as an object that stores and saves to other objects like Product and User. But the act of saving a Shopping cart, with the related logic of saving products and user data, should be split from actually running the requried series of database queries.

I've seen some ideas around using events like beforeCreate and afterCreate but that doesn't really split out buisness logic. It just seems to better organize it.



16.6k

This is an interesting topic. Could you please provide some more links? I mean some valuable articles (post etc) you have read about the idea?

edited Dec '14

I've been trying to avoid the ActiveRecord lately seeking to improve the testability of my code. What I do is to divide the models in two different kinds of objects: Domain Models and Data Access Objects (DAOs).

That way Domain Models can have business logic and be unit tested (since they don't need to access to the database, and don't have any "magic" methods tod o so), while for DAOs I rely more on integration testing.

Here's a nice post about that subject.

I just began trying Phalcon, so I'm still trying to figure out how to fit my workflow into it.

Any tips that you may have found out?