DEV Community

Discussion on: Business logic in Rails with operators

Collapse
choltz profile image
Chris Holtz

I completely agree.

In smaller rails applications, one can probably get away with mixing models with business logic, but after a certain size, it becomes a tangled mess.

Separation of concerns is important. If models are dedicated to query and data storage, and operator classes are dedicated to business logic (and presentation logic is in helper/decorator classes and configuration logic is in initializer classes, etc.), then you know exactly where to look for different types of code.

Further, pulling business logic into a PORO opens opportunities for much faster test runs, since the test suite can bypass the DB altogether for some business tests. Similarly, the operator objects in your article, for instance, allow allow one to run tests on code that would otherwise have required the slow overhead of a controller test.

While the database (and therefore model) structures inform the business operations, one does not need to dogmatically adhere to that structure in the business layer. This is particularly the case when your app also relies of data sources beyond the database or when you have multiple apps that need to read information from the same database.

Thread Thread
jaredcwhite profile image
Jared White

"If models are dedicated to query and data storage"

"While the database (and therefore model)"

Again, I fear we are treading into dangerous waters of conflating the model layer of an application with the ActiveRecord pattern specifically. You can have a wide variety of objects employing all kinds of different patterns and many of them will of course be POROs. Only some—perhaps only a few even!—of the objects in app/models need be literal ActiveRecord objects. ActiveRecord is just one pattern among numerous potential avenues of exploration in OOP.