problem with design classes to support multi languages with EJB


EJB design: problem with design classes to support multi languages with EJB

  1. Hello, We have faced a problem in our enterprise project and we think it could be resolved by Hibernate. the problem is that our project is supporting many languages, in fact, our database designed to support this feature. to enagae this feature we have two method to implementing the tables: (in order to be clear I am using Employee table as an example) 1. break a table into two tables, one contains locale-independent and the other locale-dependent informations. a table, say, "Employee": Employee (id , birthdate, ssn, employment_type) and locale-dependent table, say, EmployeeLocale EmployeeLocale (id, locale_id, given_name, family,....) 2. another way is to seperate locale-dependent information in different tables: Employee (id , birthdate, ssn, employment_type) EmployeeEnglish (id, given_name, family,....) EmployeeFrench (id, given_name, family,....) EmployeeSpanish (id, given_name, family,....) .... if information are very huge, maybe the second one has better performance. any way, the problem comes out when designing the entities and/or value objects with Hibernate. according to first method, we have a Class Employee and a Class EmployeeLocale and they have one-to-many relationship with each other. this is not good when you are working with a big project. in order to access locale-dependent informations you shoud get the Employee and then get its collection, say, "employeeLocales" and in that collection there is only one record because you requested it ,for example, with French locale. in the other hand, when you want to persist some information you should initialize the collection and then insert an instance of EmployeeLocale class into it. if you opt the second method, it has some other problem. first off, you have to create a new entity class for every locale (or every table you create) and they have the same attributes and fields (redundancy in designing entities not tables). in addition, when insetrting, for example, a new Employee in french, you should use many "if then else" statements in your codes to check if it is french then instantiate EmployeeFrench and so on. however, it will resolved using the design patterns. We are using some workaround to solve this problem, however, we had to get away some features of Spring framework like IoC. We have defined an Interface, say, Employee and an Abstract class, say, BaseEmployee that implements only locale-independent attributes and other classes that extends from that abstract class and contains locale-dependent info. and finally, we used the Command Pattern to manage the DAO classes, so, our developers only know the Employee interface and an manager that returns appropriate DAO to interact with database, of course, passing an localeId is necessary here. eventually, I think these are not good and the problem should be manipulated in EJB. I mean we should have only one Entity, say, Employee and it should be populated with requested locale in a moment, but EJB doesnt support these sort of things. In my opinion, it's better to have a new inheritance strategy for EJB that support this. I am welcome to hear your suggestion
  2. I would start by questioning your database design; it suggests that you intend to store each employee's data once for each locale. I think that this is a misguided approach because you are focussing on data that is entered by the user: you wil find that generally speaking users will tend to enter data in their own language (when business requirements permit), and in this case what you will need is a UI that will permit the user to enter text in their language and a database that accepts unicode. Multi-language/internationalisation support tends to focus more on the fixed text displayed by the application (button labels, help text etc) and this is where a set of database tables may be appropriate - although you should also check out Java's internationalisation API. If you take this aproach, the problem you describe will not exist