数据持久层位于领域层和基础架构层之间。由于对象范例和关系范例这两大领域之间存在“阻抗不匹配”，所以把数据持久层单独作为J2EE体系的一个层提出来的原因就是能够在对象－关系数据库之间提供一个成功的企业级映射解决方案，尽最大可能弥补这两种范例之间的差异。

J2EE的三层结构是指表示层（Presentation），业务逻辑层（Business Logic）以及基础架构层（Infrastructure），这样的划分非常经典，但是在实际的项目开发法中，开发者通常对三层结构进行扩展来满足一些项目的具体要求，一个最常用的扩展就是将三层体系扩展为五层体系，即表示层(Presentation)、控制/中介层(Controller/Mediator)、领域层(Domain)、数据持久层(Data Persistence)和数据源层(Data Source)。它其实是在三层架构中增加了两个中间层。控制/中介层位于表示层和领域层之间。

许多开发者用JDBC进行数据库程序的开发。此种方式很多情况下都使用DAO模式，采用SQL进行查询。虽然用此方式可以使应用程序代码与具体的数据库厂商和数据库位置无关，不过JDBC是低级别的数据库访问方式，JDBC并不支持面向对象的数据库表示。JDBC数据库表示完全围绕关系数据库模型。在大型应用程序的DAO中书写这样的代码，维护量是非常大的。

在J2EE的规范中，为EJB定义了两种持久化的解决方案：一种是BMP，另一种是CMP。其中CMP不需要将SQL语句加入到代码中。目前，在采用J2EE的应用中，EJB CMP方式得到了广泛应用。更加引人注意的是，随着EJB规范的发展，CMP也包含了一些高级关系的内容。但是，CMP的使用比较复杂，对很多开发人员来说比较难以掌握。而且，不是在所有的情况下都适合在系统中采用EJB，而且想要非常清楚的了解EJB规范也是非常费时的。在用EJB编码前，先要让专家理解API，然后需要了解每一个容器部署时所要关注的技术。此外，许多情况下商用容器的性能和支持也不是很好。

JDO是一个存储java对象的规范，JDO规范1.0的提出可以使你将精力集中在设计Java对象模型，然后在企业应用软件架构的不同层面中存储传统的Java对象（Plain Old Java Objects，简称POJOs），采用JDOQL语言进行SQL操作。一些公司（包括sun）企图根据JDO规范进行设计并实现JDO产品，然而他们都不能很好的进行实现，并且性能优化上比较差。