Ideas about Native Query for EJB3

最近，看了一下db4o这个产品的一些信息，其中 Native Query 这个概念感觉很有意义，因此，也在考虑是否可以在EJB3（Java Persistence API)中应用一下 Native Query这个概念。

按照DB4O的说法，Native Query有很多的优势：

• Modern integrated development environments (IDEs) do not check embedded strings for semantic and syntactic errors. In all the queries above, both the field age and the value 20 are expected to be numeric, but no IDE or compiler will check that this is actually correct. ("age < 20")
• If the developer mistyped the query code { changing the name or type of the field age, for example { all of the above queries would break at runtime, without a single notice at compile time.
• Since modern IDEs will not automatically refactor field names that appear in strings, refactorings will cause class model and query strings to get out of sync. Suppose the field name age in the class Student is changed to _age because of a corporate decision on standard coding conventions. Now all existing queries for age would be broken, and would have to be fixed by hand.
• Modern agile development techniques encourage constant refactoring to maintain a clean and up-to-date class model that accurately represents an evolving domain model. If query code is difficult to maintain, it will delay decisions to refactor and inevitably lead to low-quality source code.
• All listed queries operate against the private implementation of the Student class student.age instead of using it's public interface student.getAge() / student.Age and thereby they break object-oriented encapsulation rules, disobeying the object-oriented principle that interface and implementation should be decoupled.
• Developers are constantly required to switch contexts between implementation language and query language. Queries can not use code that already exists in the implementation language. There is no explicit support for creating reusable query components. A complex query can be built by concatenating query strings, but none of the reusability features of the program-ming language (method calls, polymorphism, overriding) are available to make this process manageable. Passing a parameter to a string-based query is also awkward and error-prone.
•  Embedded strings can be subject to injection attacks.
  

那么在EJB3中是否可以应用这个技术上呢？理论上，完全是可行的（或者是部分可行的），比如： "from Cat as cat where cat.mate.name like '%s%' "

可以这样来写：
new Query<Cat> {
  public match(Cat cat){ return SQL.like(cat.getMate().getName(), "%s%'") }
}