1

I'm a rails developer, and have noticed that while defining validations I find myself confused about the scope I'm trying to cover.

For example, I have basic cases where a field of data (ex: name, email, etc) needs to be present, or the correct size, format, etc.

These cases are easily handled by existing Rails validations.

But I have other cases where dependent data is required or certain combinations of data are allowed/not allowed.

In these cases I could write custom validations. However, a "user" of the application should not be exposed to a UI that could allow those types of errors.

That said, my software does have an API and if a developer does not use the API properly, he could allow for bad data if I don't add some kind of constraints to the system, be they validations or Exceptions/Errors or something else.

My thinking is... validations have pretty messages for users. Developers don't need those. Exceptions/Errors on the other hand have messages too, but they tend to be more developer oriented.

So is there a "best practices" way of thinking and approaching issues like this that could help me better organize my code so it's "easier" to extend, and separates concerns in an intuitive (or at least generally agreed upon) way?

Nathan
  • 355
  • I do not exactly understand your problem. Anyway: The ActiveRecord validations main goal is to actually ensure data integrity. It doesn't matter where the data comes from, it's on the model level, so part of the business rules. Also what's the difference between 'validating user input' and 'ensure data integrity'? You validate user input to ensure data integrity. (Data integrity being a bit of a broad term, meaning basically 'valid data'). What additional 'features' does your API have that are different from the normal user input? – thorsten müller Jul 28 '15 at 13:49
  • @thorstenmüller Well that is the question, so seems you understand it fine. The issue is that with user input, the cases I need to account for are fairly limited. If on the other had I extend validations to cover the external API... then the internal API, then just general constraints to avoid developer errors.. the number of cases will be nearly infinite. I'm trying to understand what the best way to approach this area of programming is. – Nathan Jul 28 '15 at 13:53
  • Why does it seem wrong? Certainly it might be redundant, if the API already provides its own validation. Check the API documentation. – Robert Harvey Jul 28 '15 at 14:00
  • Adding another comment to answer your last question more directly. My data model has cases where dependencies exist (ex: some data must exist before other data). Also, my data model has cases where certain combinations are invalid. The API does not restrict the developer around these areas... and instead assumes he will build a UI that will prevent incorrect user error. – Nathan Jul 28 '15 at 14:01
  • @RobertHarvey what API documentation? I'm writing the API. – Nathan Jul 28 '15 at 14:01
  • The validations should ensure valid data, this includes basically everything that possibly could go wrong. So: yes, the model is the place that ensures that only valid data goes into the database. That's at the core of the MVC model. You can not really depend on the UI for validations, especially in the browser the user can turn those off anyway and send any data he likes (don't trust the browser!). Also any other place would mean you would possibly duplicate validation code. In general the model is 'best practice' for all validations. – thorsten müller Jul 28 '15 at 14:04
  • Then I fall back on my original question... Why do you think that validating the data entering your API is a wrong approach or a bad idea? – Robert Harvey Jul 28 '15 at 14:07
  • @thorstenmüller Mmm, you're getting into where the validations live in rails -- which is a contentious subject. Also, the API in my app (as in most APIs) does not imply an onus on UI validations. The validations are server side. But currently they address fields of data. Name, phone, etc -- concerned with format, size, etc. In terms of "data integrity" as I've mentioned, I have cases where only certain combinations of data should be allowed. Or certain data must be entered first. This is currently not enforced by validations in the API. – Nathan Jul 28 '15 at 14:10
  • Rails religions are overrated. Validate your data. If Rails doesn't provide a suitable way, write some code that does. – Robert Harvey Jul 28 '15 at 14:11
  • @RobertHarvey Well, validations have pretty messages for users. Developers don't need those. Exceptions/Errors on the other hand have messages too, but they tend to be more developer oriented. So in my mind, the notion of using validations for data integrity at the developer level is not the right tool for the job. That's what prompted my asking this question. – Nathan Jul 28 '15 at 14:14
  • Now we're getting somewhere. If you can modify your question to include that thought process (and anything else that will make your question more specific), you could avoid your question getting closed. Though, to be fair, the prettiness of a validation message shouldn't really be a factor; presumably the message already has the information the developer needs to fix it (i.e. "This field is required"), and the developer doesn't need a stack trace to fix that. – Robert Harvey Jul 28 '15 at 14:15
  • @RobertHarvey you can write arbitrary code for validations. There are basic validations for size, data type, existence of related records etc, but you can easily add complete methods for more complex validations. So the question would be mainly about those validations being in other places. Like the controller? This seems wrong. Even if you decide to have different validations for the API and the UI you should still put them into the model area. – thorsten müller Jul 28 '15 at 14:18
  • @thorstenmüller: Sounds like good fodder for an answer, if you can make it more specific. – Robert Harvey Jul 28 '15 at 14:19
  • @RobertHarvey I just edited the question. Better? – Nathan Jul 28 '15 at 14:19
  • @Nathan: You're going to have to be more specific about what you mean by "right." We don't know what that word means to you. Best performing? Least amount of code? Most likely to win a beauty contest? – Robert Harvey Jul 28 '15 at 14:20
  • @thorstenmüller Sorry, you're on the wrong track here. I don't care where they live. I have my own pattern for that anyway. – Nathan Jul 28 '15 at 14:20
  • Really the type of error message should not be relevant for such a design decision. In worst case I would limit the validation error messages to strings with error codes and then add different helpers for API and UI that 'translate' those codes into real text. – thorsten müller Jul 28 '15 at 14:21
  • @RobertHarvey I just re-wrote the question, let me know if you think this helps. – Nathan Jul 28 '15 at 14:29
  • @thorstenmüller Is what you're suggesting a best practice? – Nathan Jul 28 '15 at 14:30
  • Better, but I still think "this is a required field" is a suitable message for both a developer and a user. – Robert Harvey Jul 28 '15 at 14:31
  • @RobertHarvey I've covered that when describing basic validations. Those case are straight forward and easily handled by built-in Rails validations. But when the integrity of the data drifts into a more complex territory like the existence of dependent data, the the user should not be exposed to any UI that would allow for him to see that case. It's up to the developer to build the right UI to insure dependent data gets entered first. – Nathan Jul 28 '15 at 14:36
  • Then it sounds like you've answered your own question. Seriously, don't let a bunch of strangers tell you what the "right" way is to do something. Just look at your options, evaluate your requirements, and then write some code that fulfills them. – Robert Harvey Jul 28 '15 at 14:37
  • Well, not really. This is what my original question stated... I sense that using validations in these cases is "not the right tool for the job" but am posting here to listen to what others have to say on the issue. I'm hoping to find a more educated answer than my own. – Nathan Jul 28 '15 at 14:39
  • I can't tell if you're asking specifically about how to use what Rails calls validations, or if you want general advice on what kinds of checks belong in the DAL versus the BLL or the UI. – Ixrec Jul 28 '15 at 17:41
  • @Ixrec I'm not interested in where the checks live, and no, this is not Rails specific. I'm concerned with "validations" as an implementation concept and what they're supposed to cover. As I pointed out, there are exceptions/errors in apis that provide a similar constraint but are not data specific; although they could be. So I'm looking for feedback that provides clear definitions around this stuff -- in particular around more complex data integrity cases (ex: when cross-table combinations are allowed/disallowed). – Nathan Jul 29 '15 at 08:58

0 Answers0