Is application level validation logic enough to maintain data consistency

Question

In our project we have a user who can have many credit cards. He should only have one default (boolean: true) at a time. From the current UI and the current application logic, it is impossible to have more than one. But if you open a rails console you can change and have more than one.

Is it a good practice to write some extra code, which it will check all the credit card records of a user, restricting the number of default credit cards to one on the model level? Or is this over-engineering?

Answer 1

I would prohibit it in the model, especially if it would break if there were two defaults. That way a future programmer will know that it's bad and, if he doesn't notice and does it anyway, he will be informed.

Answer 2

On my opinion, writing additional validation is a good practice. Models is a place for code related to persistent business objects (rely on Rails conventions). If you business object user has a collection of credit cards and this collection has some business rules, it should be described in a model.

Some arguments:

• Just imagine: in 2 years in future your CEO can say "Hey guys, we have to build modern UI, throw this current erb templates away and lets use X." And frontenders, who will be hired for X, may miss the business rule for credit cards.
• Internet is very scary place where many hackers are doing their dark things. Especially on websites found in Google by keywords "credit card collection". They can send some manually prepared HTTP requests to brake your system. You should never put your safety on HTML temlpates or JS client-side applications.