1

I've been working over 10 months on a legacy project (yes, in PHP, what a surprise!) that has database IDs hardcoded all over the codebase. Of course this makes problems like we can't maintain it w/o a production dump, no tests, etc. I already vomited over that.

Moving on, there is one particular case that I can't see how would I NOT hardcoded a dynamically generated content:

There is a screen with a form, and at the side a "help" button that is a link to the "company politics" regarding the info on that form.

Said politic is dynamically created, updated, Etc. by one of our departments, in a different module of our system.

I don't see a way of not-hardcoding the url /politics/12 on said button; and since there is probably a delete action in the politics module, a way to prevent it from break if deleted.

How are components (like said form) that depends on dynamically generated resources are designed?

Improve this question

1 Answer 1

Reset to default
2

This becomes a issue when: 1. There is a concept of lookup values (an invalid concept outside of DDD) 2. An application is designed around the database instead of around conceptual entities

Introducing an application specific natural key could be helpful here, it is okay for values of departments to be hardcoded, an application can never, nor should be, completely dynamic.

You have a hard coded key, 'Department', in the database, relate the 'Department' to the text blurb id 12. The text blurb, not the department is what needs to be dynamic.

Then your url can look like this: /polictics/department

Improve this answer
4
  • So, in simpler words, I should have a database value that's always guaranteed to be there. A non-deletable record. That way, the system is able to depend on it. Did I understand it correctly?
    – Christopher Francisco
    Commented Jul 21, 2017 at 20:39
  • @ChristopherFrancisco This key is defined in code... and it may or may not be guaranteed in the DB (although, I guess in your case you'd want it to be); you use this value defined in code, to reference the appropriate record(s) in the DB
    – TheCatWhisperer
    Commented Jul 24, 2017 at 14:39
  • @ChristopherFrancisco the conceptual mistake that you are making is, you are seeing the DB as the application, and the code as just a means of displaying that application. This is incorrect, you need to start seeing the database as only a means of storing data for the application.
    – TheCatWhisperer
    Commented Jul 24, 2017 at 14:41
  • That part I understood. But I'm asking about the dependency that the code have on the existence of that specific record. A different example would be a RBAC system, where permissions like customer.create or invoice.delete are referenced in the code, but they are stored in the database for querying purposes (users N:M roles N:M permissions).
    – Christopher Francisco
    Commented Jul 24, 2017 at 15:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.