7 ms·

> Write high-level abstractions for everything that is not your core business domain, and don't let secondary component concepts leak into your business domain.

> Write high-level abstractions for everything that is not your core business domain, and don't let secondary component concepts leak into your business domain. This kind of seems really obvious.

qznc 9y ago
I have yet to see a web service where the database interactions do not leak into the business code.
- Omnius 9y ago
  Can you elaborate what you mean by this. What would an example of the bad practice look like verse if it had been done correctly? If i understand you basically any time a developer uses an orm he would be mixing the DB interactions with business logic but i want to be sure what you mean. Thanks!
  - qznc 9y ago
    I would not label it bad practice. Honestly, I'm not sure if there is a simple rule to decide what is good or bad. Using an ORM is not necessarily mixing in DB interactions. Here is an example from the Django documentation [0]: selected_choice.votes += 1 selected_choice.save() The offender in my eyes is the save() method call. The first line is business logic, but the second line has nothing to do with business logic. It might be slightly better to hide the database interaction in the object itself, create a special method, and change the two lines into: selected_choice.increaseVotes(1) As a counter argument, I dislike code which hides database accesses, because that easily leads to code which does way to many of them and thus is unnecessarily slow. [0] https://docs.djangoproject.com/en/2.0/intro/tutorial04/ https://docs.djangoproject.com/en/2.0/intro/tutorial04/
    - acdha 9y ago
      The second argument should also include correctness: if I increment two variables on that object (e.g. votes and last_vote_time) it needs to be a single atomic operation to not create a hard to debug race condition. It seems better to explicitly say when to save things rather than hope that every custom method does that and you have a method for every combination of updates. The Django ORM also has another case to consider: bulk updates, where separating logic from serialization makes a huge performance win easy and safe.

> Write high-level abstractions for everything that is not your core business domain, and don't let secondary component concepts leak into your business domain. This kind of seems really obvious.

qznc 9y ago

I have yet to see a web service where the database interactions do not leak into the business code.

Omnius 9y ago
Can you elaborate what you mean by this. What would an example of the bad practice look like verse if it had been done correctly? If i understand you basically any time a developer uses an orm he would be mixing the DB interactions with business logic but i want to be sure what you mean. Thanks!
- qznc 9y ago
  I would not label it bad practice. Honestly, I'm not sure if there is a simple rule to decide what is good or bad. Using an ORM is not necessarily mixing in DB interactions. Here is an example from the Django documentation [0]: selected_choice.votes += 1 selected_choice.save() The offender in my eyes is the save() method call. The first line is business logic, but the second line has nothing to do with business logic. It might be slightly better to hide the database interaction in the object itself, create a special method, and change the two lines into: selected_choice.increaseVotes(1) As a counter argument, I dislike code which hides database accesses, because that easily leads to code which does way to many of them and thus is unnecessarily slow. [0] https://docs.djangoproject.com/en/2.0/intro/tutorial04/ https://docs.djangoproject.com/en/2.0/intro/tutorial04/
  - acdha 9y ago
    The second argument should also include correctness: if I increment two variables on that object (e.g. votes and last_vote_time) it needs to be a single atomic operation to not create a hard to debug race condition. It seems better to explicitly say when to save things rather than hope that every custom method does that and you have a method for every combination of updates. The Django ORM also has another case to consider: bulk updates, where separating logic from serialization makes a huge performance win easy and safe.