Reuse your Hibernate/JPA domain model with Grails

Reuse your Hibernate/JPA domain model with Grails

Peter Ledbrook

It's a common story. You have an existing database and now you want to add a web application for it with the minimum of fuss. Is Grails up to the task? Of course it is! Even better, if you already have a domain model based on JPA or Hibernate configuration files, you can reuse it and still benefit from the great GORM features you're used to.

The first step in reusing an existing domain model is to get the class files on the application's classpath. You can do this either by packaging them up in a JAR file and including it in the application (typically by dropping it in the 'lib' directory), or by putting the source files in the 'src/java' directory. The JAR file is the better approach when sharing a model between applications, but you then need a multi-project build system to ensure that the JAR is always up to date for all projects. It's probably worth the extra effort and both Gradle and Maven have plugins for building Grails projects. Alternatively, if your Grails application is the only project using the model going forward, you should keep the source in 'src/java' instead.

Once you've decided on how to incorporate the domain model, you need to tell Grails about it. How you do that depends on whether you're using Hibernate configuration files or JPA annotations.

XML configuration files

Hibernate XML mapping files are old school, but they have the advantage of keeping all the mapping information in one place. To use them from your Grails application, simply create the file grails-app/conf/hibernate/hibernate.cfg.xml with the content:

01 <? xml version = '1.0' encoding = 'UTF-8' ?>
02 <!DOCTYPE hibernate-configuration PUBLIC
03          "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
05 < hibernate-configuration >
06      < session-factory >
07          < mapping resource = "org.example.Book.hbm.xml" />
08          < mapping resource = "org.example.Author.hbm.xml" />
09          ...
10      </ session-factory >
11 </ hibernate-configuration >

Make sure you add a <mapping> element for each of your Hibernate mapping files and drop those mapping files into grails-app/conf/hibernate . Amazingly, that's all you have to do! So what about annotated models?

JPA annotations

As with the Hibernate mapping files, you have to create the grails-app/conf/hibernate/hibernate.cfg.xml file. This time, you've got a bit more work to do as you have to add a <mapping> entry for every domain class:

01 <? xml version = '1.0' encoding = 'UTF-8' ?>
02 <!DOCTYPE hibernate-configuration PUBLIC
03          "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
05 < hibernate-configuration >
06      < session-factory >
07          < mapping class = "org.example.Book" />
08          < mapping class = "org.example.Author" />
09          ...
10      </ session-factory >
11 </ hibernate-configuration >

Not much fun I grant you, but at least you only have to do it once.

If you're using Grails 1.1.x or earlier, there's one more task to undertake: you have to tell Grails that this is an annotation-based model by adding the following to grails-app/conf/DataSource.groovy :

1 dataSource {
2      configClass = "org.codehaus.groovy.grails.orm.hibernate.cfg.GrailsAnnotationConfiguration"
3      ...
4 }

You don't have to do this for Grails 1.2+ because GrailsAnnotationConfiguration is the default setting in those versions. Next time you run your Grails application, you'll have access to all your annotated domain classes.

Note Since version 1.3.2, you have been able to use the Grails command create-hibernate-cfg-xml to generate the Hibernate configuration file for you. Saves typing/copy-pasting!

One glaring gap remains in the domain model from a GORM standpoint: constraints. You can't define them in your Java classes, but without them, GORM validation is useless. Fortunately, you can attach constraint metadata to a class by adding a package.DomainClass Constraints.groovy script to 'src/java'. For example, if you have a domain class org.example.LibraryBook , then you should add the file src/java/org/example/LibraryBookConstraints.groovy . Inside this script you define your constraints block like so:

1 constraints = {
2      name(blank: false)
3      age( min : 0 , max : 120 )
4      ...
5 }

You may be wondering why the script goes in the 'src/java' directory. That's a good question. Grails requires the constraints script in source form, so you need to put it in a location which results in Grails including the .groovy file (not the compiled class) in the WAR. The 'src/java' directory is the only location that satisfies this requirement.

It really is surprisingly simple to incorporate a Java domain model in your Grails applications. You may lose the elegance and custom mappings of standard GORM domain classes, but you are still able to use dynamic finders, criteria queries, validation, etc. What about scaffolding? Grails will do its best to scaffold your domain model, but it makes no guarantees. As long as the model is straightforward, the scaffolding should work fine. Reusing a domain model is also a great way of trying out Grails since you don't have to create one from scratch.

Note that if you simply want to access a legacy database and don't have an existing domain model, then you are almost certainly better off using standard GORM domain classes with custom mappings. Both approaches are documented in the user guide: Hibernate mappings and the custom mapping DSL .

One final thing: if you've used a Java domain model in your own Grails project, I'd be interested to hear about your experiences. Anything that can help other users who want go down this path would be much appreciated!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在信号处理领域,DOA(Direction of Arrival)估计是一项关键技术,主要用于确定多个信号源到达接收阵列的方向。本文将详细探讨三种ESPRIT(Estimation of Signal Parameters via Rotational Invariance Techniques)算法在DOA估计中的实现,以及它们在MATLAB环境中的具体应用。 ESPRIT算法是由Paul Kailath等人于1986年提出的,其核心思想是利用阵列数据的旋转不变性来估计信号源的角度。这种算法相比传统的 MUSIC(Multiple Signal Classification)算法具有较低的计算复杂度,且无需进行特征值分解,因此在实际应用中颇具优势。 1. 普通ESPRIT算法 普通ESPRIT算法分为两个主要步骤:构造等效旋转不变系统和估计角度。通过空间平移(如延时)构建两个子阵列,使得它们之间的关系具有旋转不变性。然后,通过对子阵列数据进行最小二乘拟合,可以得到信号源的角频率估计,进一步转换为DOA估计。 2. 常规ESPRIT算法实现 在描述中提到的`common_esprit_method1.m`和`common_esprit_method2.m`是两种不同的普通ESPRIT算法实现。它们可能在实现细节上略有差异,比如选择子阵列的方式、参数估计的策略等。MATLAB代码通常会包含预处理步骤(如数据归一化)、子阵列构造、旋转不变性矩阵的建立、最小二乘估计等部分。通过运行这两个文件,可以比较它们在估计精度和计算效率上的异同。 3. TLS_ESPRIT算法 TLS(Total Least Squares)ESPRIT是对普通ESPRIT的优化,它考虑了数据噪声的影响,提高了估计的稳健性。在TLS_ESPRIT算法中,不假设数据噪声是高斯白噪声,而是采用总最小二乘准则来拟合数据。这使得算法在噪声环境下表现更优。`TLS_esprit.m`文件应该包含了TLS_ESPRIT算法的完整实现,包括TLS估计的步骤和旋转不变性矩阵的改进处理。 在实际应用中,选择合适的ESPRIT变体取决于系统条件,例如噪声水平、信号质量以及计算资源。通过MATLAB实现,研究者和工程师可以方便地比较不同算法的效果,并根据需要进行调整和优化。同时,这些代码也为教学和学习DOA估计提供了一个直观的平台,有助于深入理解ESPRIT算法的工作原理。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值