4 ms·
Business logic. +if you only look at the data side, most business objects don't have the same shape as database rows, yet most CRUD programming is tightly bound
by dreamfactored 9y ago
Business logic. +if you only look at the data side, most business objects don't have the same shape as database rows, yet most CRUD programming is tightly bound to table representation.
- davidjnelson 9y agoYou could do the transformation before it hits the ui, and for ui specific business logic, call into it from the higher order components that wrap the common components provided by the community.
- dreamfactored 9y agoThis is the job of a model. Say I want to manage videos and their rights as they relate to territory, time, and user; or I want to create contracts between my customers and financial exchanges allowing them to access specific data feeds, each with its own additional contract, regional and volume usage limits, and SLA's. And these are synthetic simplified examples I just pulled out of the air - real life is way more intricate. Let's not even get into multilingual and versioning for audit trails. What I don't want to care about is storage implementation to implement those models in a given channel/client. If that starts leaking through the model abstraction layer into implementation, my business rules aren't testable, I can't change backends to scale without rewriting all my implementations, all of which are going to be bug-ridden and spaghettified. The fact that we would even describe storage as a transformation (as if it was just a mapping with some consistency rules), should flag up how brittle such an approach is going to be. No wonder it is so painful for businesses to make any changes to their systems. Now having said that there are many simple cases that do map well to a table. Those are already managed directly by businesses without the assistance of developers - in spreadsheets.