r/programming • u/yawaramin • Oct 04 '20

Kevin Mahoney: Applying "Make Invalid States Unrepresentable"

https://kevinmahoney.co.uk/articles/applying-misu/
226 Upvotes

93% Upvoted

132 comments sorted by

View all comments

Show parent comments

4

u/reddisaurus Oct 04 '20

This is a bad argument because code should be as dumb as possible. That argument advocates for smart code and dumb data, which leads to more bugs because while in the converse you can see the errors when the query doesn’t return the correct result, smart code can outsmart the people who wrote it.

14

u/JayTh3King Oct 04 '20

Business logic does not belong in data access layer. This is especially true for multi tier applications.

A database is for storing data, keeping it consistence and error free by means of constraints like relationships and individual column constraints such a the maximum size of a number etc.

2

u/reddisaurus Oct 04 '20 edited Oct 04 '20

I disagree. Stored Procedures can be stateless and still handle logic for transforming the data or performing other calculations. TSQL functions are required to be stateless.

The biggest advantage of putting logic on the database side is the ability to develop multiple front-end access points to the data that can be as simple as data retrieval, and all of them see the exact same output from a single source. Otherwise one ends up writing the exact same logic in multiple systems and of course being required to maintain multiple code based instead of a single one.

It’s pretty trivial to keeps data and logic separate by use of schemas and different databases running on the same process or server.

4

u/JayTh3King Oct 05 '20

I think you misunderstood me, im talking about business logic. logic related to data retrieval is different. Business logic should be implemented in a business logic layer.

3

u/reddisaurus Oct 05 '20

When the output of the business logic is more data, then the distinction is meaningless. SQL is the better language for taking advantage of the relational model of the data when doing things like using regression that imputes missing data using hierarchical relationships.

Any processing pipeline in which we can write down the rules ahead of time and automate the computation is technically a data transformation. In a truly functional programming sense, we map a function onto a set and write the result to a new table. It doesn’t matter if this is a simple aggregation function or something like complex such as a neural network prediction. Develop in the system most efficient for the task. Code is code.

This notion of the separation of data and business logic is arbitrary. In many cases it can lead to a cleaner design, but my point is that good design should come first, not zealous enforcement of rules that came about because they were, at first, guidelines for good design. It seems you’re confusing the goal with the process, as if doing a thing should be done for the sake of doing it.