Collected Java Practices

Here's yet another site with some collected practices for Java Programming. I just surfed over some practices without diving into details, but I decided to read the "data is king" practice, as it clearly opposes to the "database is a detail" saying.

I pretty much agree with everything but I feel a shiver down my spine when I read the following sentence:

the data is always validated before being entered into the database (this cannot be stressed enough)

What's wrong with it? well, nothing at all, on the contrary! but it gets creepy when you put it with another sentence:

applications should never assume that they "own" the data. Databases are independent processes, and are built to interact with many clients applications, not just one

That forces me to meditate. IMHO, the first sentence is a perfect example of a too unused good theory, the second one describes a too diffused bad practice.


If data must always be validated (and it should!), and databases should interact with many client applications, each application must ensure the same data validation process happens. That means duplication, and (IMHO) it smells.

One could easily agree that moving the data validation process into the database would suffice to solve the problem, for example using stored procedures, triggers and rules. But then, the database should support these means, which leaves out, for example, flat files. Moreover, switching to a different database would be very difficult.

So what? as always, a very consolidated habit of communicating between peers can come to help: as it is a fact that many applications write to the very same database, everybody who is involved should ensure that the overlapping areas are as small as possible and that they deal with data in the same way, either with "database programming" or "people synchronization", thus reducing duplications and error sprouting.

Another solution can be one application exposing services used by the other ones, but sometimes this is not desirable or applicable.

That said, I want to stress the "no silver bullet" concept: "data is king" surely is a good advice but it cannot be taken as an absolute truth but as a general rule. The same applies, for example, to GRASPs: when you have to decide which class should create a new instance of another class, should you follow the Creator pattern or the Expert pattern? it depends, but the important thing here is that they can lead to very different results, each of which would have its proper rights to stand as a correct solution. It is our responsibility to derive our decisions on the basis of all our knowledge and experience - there's no magic involved, even if sometimes a design comes out naturally, just because "you know it's right": this lucky feeling comes from experience and a very long try-and-fail process. Only keep in mind that what you do can, most of the times, be further improved :-) so be humble and ask... you might be surprised!