correct way to model isbn number in j2ee app

I am trying out a web app using servlets and jsps and need to model isbn number of an item in my class as well as in hibernate mappings. Which should be the type of an isbn number?Long or String? I had come across many tutorials that use either of them.. isbn is supposedly a 10 digit identifier..sometimes you come across numbers like 0-85131-041-9 which cannot be a Long ..Some examples use numbers without hyphens..

So,w开发者_JAVA百科hich should be the type? Any suggestions?

thanks

mark

---

ISBN has 13 digits (see wiki). I would use a class that checks the validity of given String. Something like:

class ISBN {
  private String isbn;
  public ISBN(String isbn) throws ISBNFormatException {
    // you might want to filter hyphens first, before the check
    if(ISBN.isValid(isbn)) this.isbn = isbn;
    else throw new ISBNFormatException(isbn);
  }
  public static boolean isValid(String s) {
   // validate number here, see wiki
  }
}

This, of course, may be a bit too much. If your app is really simple, you may go with String just fine.

Edit The hyphenation divides the number into groups (language, publisher, etc.). However, as for the uniqueness of the number, hyphenation (or division with spaces) plays no role.

---

Actually ISBN are not 10 digits but 12 digits + a check ISBN FAQ The check can be an X

The method of determining the check digit for the ISBN is the modulus 11 with the weighting factors 10 to 1. The Roman numeral X is used in lieu of 10 where ten would occur as a check digit.

If you are storing information that a user has typed in then you should include the check digit and so this has to be a string.

If you are storing the actual ISBN then you can ignore the check as you can calculate it. However if using the new 12 digits the numbers are greater than a long can hold, if the old 10 digits then it could be held in a long but you would have to remember to possibly add leading 0s back. Thus in this case I would hold it in a string removing all non numeric data e.g. hyphens.

Also looking at that FAQ there is a possible reason to store the ISBn split up to allow searching by parts.

The five parts of an ISBN are as follows:
1. The current ISBN-13 will be prefixed by "978"
2. Group or country identifier which identifies a national or geographic grouping of publishers;
3. Publisher identifier which identifies a particular publisher within a group;
4. Title identifier which identifies a particular title or edition of a title;
5. Check digit is the single digit at the end of the ISBN which validates the ISBN.

and 5 does not need to be saved as it can be calculated but does need to be captured from users to validate entry.

---

This question doesn't really have anything to do with J2EE, but simply with Java datatypes and maybe the data types on your database engine.

If you want to include the hyphens in any output, than you pretty much have to store it as a string. Unless you want to write code to figure out where the hyphens go, but the rules behind that are fairly complicated, depending on values of digits at the beginning of the number. (If you're working on a system that assigns ISBNs or takes them apart and works with the pieces, maybe you want to do this. If you just want the user to type it in and you remember it, this sounds like too much trouble.)

I guess if you don't care about the hyphens, you could use a String or a long. Still, a long would be an extra pain in that you'd have to figure out when to display leading zeros.

Short answer: I don't see any advantage to storing it as a number. Use a string.

---

I'd store it in a Long property and use a formatter/parser (essentially, a converter). When you're going to display it, the converter should just convert the Long property to a human representation with hyphens in the right places. When you're going to validate/persist it, the converter should remove all hyphens from the submitted value and put it in a Long property.

Basically, it's the same idea as you would use for a Date field which you format/parse in the human representation with help of SimpleDateFormat. The only difference is that the ISBN formatter/parser isn't available by the standard Java SE API. You'd need to write one yourself or to adopt a 3rd party one (of which none existing comes to mind though). Finally this converter can then be used as a JSP tag (like JSTL's <fmt:formatDate>) or a standalone Java class which is invoked by an EL function or when you're using JSF, a @FacesConverter class.

Due to the complexiteit of the ISBN number, this is indeed more than often stored as a String so that the developer doesn't need to worry about valid patterns. Whether that's good or bad is a question that you've to ask yourself and your team.