I am a freelance web developer since 2007. I’ve started as HTML & CSS coder (in time of IE 6). Then as PHP (and WordPress) developer. Since 2015, I am working with Ruby on Rails.
Location
Prague, Czech Republic
Education
Master of Business Informatics, University of Economics, Prague
Thanks for the feedback. The reason is, that I don't want to have the business logic inside the model. I want to have models as a place for things mostly related to the database (like validations and associations and so).
Models with business logic inside have too many responsibilities.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the feedback. The reason is, that I don't want to have the business logic inside the model. I want to have models as a place for things mostly related to the database (like validations and associations and so).
Models with business logic inside have too many responsibilities.
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.