现在，我正在制作一个非常简单的网站，大约5页。问题是，整合某种类型的数据库映射解决方案是否过时且值得花时间，或者仅使用简单的旧JNDI会更好。我可能需要从数据库中读取/写入很多东西。我想我对这些技术有基本的了解，但是仍然需要大量参考文档。还有其他人面对过这个决定吗？

编辑：对不起，我应该指定JNDI来查找数据库连接和JDBC来执行操作。

解决方案

对于一个非常简单的应用程序而言，这似乎显得有些矫kill过正，尤其是如果我们没有计划对其进行扩展的话。但是，似乎也值得在此简单应用程序中使用它们，以便我们下次可以使用它们时更好地了解它们的工作方式。

我们是说普通的JDBC吗？
一个小型项目可能是选择一个ORM框架的好机会，特别是如果我们有时间的话。

但是，如果没有更多信息，很难以一种方式或者另一种方式提供建议。

简短的答案：这取决于我们要支持的复杂性。

长答案：

首先，ORM(即我们所称的对象关系映射数据库映射)和JNDI(Java命名和目录接口)是两种不同的事物。

如我们所知，第一个用于将数据库表映射到类和对象。第二个是为资源提供查找机制，它们可以是DataSources，Ejb，Queues或者其他资源。

也许意思是" JDBC"。

现在，对于问题：如果可能就这么简单，则无需实施ORM。我猜数字表最多只能有5 10个左右，而且操作真的很简单。

大概使用普通的JDBC就足够了。

如果使用DAO模式，则可以在以后更改它以支持ORM策略(如果需要)。

像这样：
假设我们有Employee表

我们可以使用数据库的所有字段手动创建Employee.java(不应花费太长时间)，并使用以下方法创建EmployeeDaO.java：

+findById( id ): Employee
+insert( Employee ) 
+update( Employee )
+delete( Employee ) 
+findAll():List<Employee>

实现非常简单：

select * from employee where id = ?
insert into employee ( bla, bla, bla ) values ( ? , ? , ? )
update etc. etc

当(和如果)应用程序变得太复杂时，我们可以更改DAO实现。例如，在"选择"方法中，我们可以更改代码以使用执行该操作的ORM对象。

public Employee selectById( int id ) {
      // Commenting out the previous implementation...
      // String query = select * from employee where id = ? 
      // execute( query )  

      // Using the ORM solution

       Session session = getSession();
       Employee e = ( Employee ) session.get( Employee.clas, id );
       return e;
}

这只是一个示例，在现实生活中，我们可以让表象工厂创建ORM DAO，但这是题外话。关键是我们可以从简单开始，通过使用设计模式，可以在以后根据需要更改实现。

当然，如果我们想学习技术，那么即使只有一张桌子，我们也可能会陷入僵局。

一个或者另一个(即ORM解决方案)的选择基本上取决于我们所使用的技术。例如，对于JBoss或者其他开源产品，Hibernate很棒。它是开源的，有很多可以学习的资源。但是，如果我们使用的是已经具有Toplink的产品(例如oracle应用服务器)，或者如果基础已经在Toplink上构建，则应该使用该框架。

顺便说一句，自从甲骨文收购BEA以来，他们说他们正在用现在称为" Oracle Weblogic Application Server"的toplink替换Kodo(weblogic持久性框架)。

我为我们提供了一些资源，我们可以在其中获得有关此信息的更多信息：

在这本《企业应用程序体系结构模式》一书中，马丁·福勒(Martin Fowler)解释了在哪里使用一个或者另一个，这里是目录。看一下数据源架构模式与对象关系行为模式：

PEAA目录

DAO(数据访问对象)是核心J2EE模式目录的一部分：

DAO模式

这是Hibernate的入门教程：

冬眠

Toplink的官方页面：

顶联

最后，我"认为" JPA的好主意是我们最近可能会更改提供者。

从简单开始，然后发展。

我希望这有帮助。

我的经验法则是，如果它是只读的，我愿意在JDBC中进行操作，尽管我更喜欢将空的Hibernate项目与SQLQuery一起使用，以利用Hibernate的类型映射。一旦要做写操作，我就选择了Hibernate，因为设置几个属性然后调用save比分别设置每个列要容易得多。而且，当我们必须开始优化以避免对未更改的对象进行更新时，使用OR / M及其脏检查会更好。处理外键关系是我们需要先映射一次然后使用吸气剂的另一个标志。相同的逻辑也适用于Toplink，尽管除非他们在我使用它以来的3年中添加了HQL之类的东西，否则Hibernate对于这种从纯SQL过渡的方法会更好。请记住，我们不必映射每个对象/表，只需映射有明显优势的对象/表即可。以我的经验，大多数不使用现有OR / M的项目最终都会建立一个新的OR / M，这是一个坏主意。

学习ORM的最好方法是在一个小项目上。开始这个项目。

一旦掌握了窍门，就可以使用ORM进行所有操作。

对于ORM来说，没有什么太小。在完成最初的几个项目之后，我们会发现我们无法以其他任何方式进行工作。通常，ORM映射比几乎任何其他工作方式都有意义。