2

我正在构建一个基于 JSF-Spring-Hibernate 的应用程序，它需要将内容存储为 pdf、MS Office 文件等。我正在考虑为其提供 JCR 功能，添加 Jackrabbit 或 Modeshape 即但我仍然有一些疑问。

  • 我们实际上将内容作为原始文件存储在文件系统中，并在我们的 MySql 数据库中添加对它们的引用。该数据库表还保留有关修改、版本等的信息。这样可以很容易地检索有关每个组、每个用户等上传文件的数据。使用 JCR API 是否如此直接？此外，是否有可能将文件保持在文件系统中并将元数据信息存储到 MySQL 中，就像我们实际上正在做的那样，但使​​用 JCR？

  • created by - updated by字段实际上存储在 DB 表中，并在我的应用程序中引用系统用户，但 JCR 实现似乎有自己的身份验证系统。我想这里要走的路是在系统的每个用户创建一个新用户到 JCR 实现中创建？密码更新呢？是否建议将用户系统密码与存储库中的密码保持同步？还是对存储库中的每个用户使用相同的密码就足够了？

  • 我们经常用一种以上的语言处理相同的文件。在这种情况下，文档版本相同，但文件之间的语言不同。我已经看到规范中有一个jcr:language属性，这可以用于那个吗？

  • 我可以看到的另一个可能的问题是，例如，我们目前没有控制组名中的名称重复。可能有两个相同的组名，并且为了将它们的目录与文件系统不同，我们使用它们的 DB id 附加到目录路径中的名称。我不知道这是否真的是一个最佳实践以及我们如何通过 JCR 实现来管理它......

PD：我的 servlet 容器是 Tomcat 6。

汇集你的想法！

4

1 回答 1

2

您已经说过您已经依赖 Hibernate 和 MySQL 来存储大部分数据并将文件存储在文件系统上。你希望 JCR 能带来什么？什么是 Hibernate、MySQL 和/或文件系统不够用？您当前的架构是否难以扩展或集群？您在编写同一个文件时遇到并发问题吗？您的实体类是否受到限制？你是实体形成层次结构吗，因为这对于 Hibernate 和关系数据库来说通常很困难？

您必须考虑更改当前架构以添加全新的数据存储技术，这一定是有原因的。

假设您只想将文件内容存储在 JCR 存储库中，而不是存储在文件系统中。是的，这会起作用，而且它可能会稍微简化您的应用程序，并使用更少的代码使其更容易。但是，这种好处是否值得在您的应用程序中添加 JCR 实现的复杂性？（只有你能回答这个问题。）

或者您是否也在考虑使用 JCR 而不是 Hibernate。有些人觉得这很难想象，但在某些情况下（尤其是当您的实体大多是类似地图的数据结构时）JCR 实际上可以比 Hibernate 更干净地存储信息。

将您的数据存储在 JCR 中意味着每个“实体”都由一个节点和属性（可能还有更复杂实体的子节点）表示，并且这些实体将存储在分层结构中。您可以在使用通用节点类型时完成所有这些操作（例如nt:unstructured)，或者您可以选择为每种类型的实体定义一个节点类型。使用 mixin 类型和残差属性定义，您甚至可以允许单一类型实体的节点在它们持有的信息类型上有所不同：所有客户节点可能包含客户 ID、名字、姓氏和其他一些位信息，但有些客户有其他信息（会员 ID、memberSinceDate 等），您只需添加到相应的客户节点即可。随着您的需求随着时间的推移而变化，存储在节点上的数据可以很容易地随之发展，有时甚至无需修改您的节点类型（顺便说一句，无需重新启动应用程序或者如果您提前计划而不需要您更改您的应用程序代码）。

简而言之，使用 JCR 作为数据库可以为您提供极大的灵活性，即使在您的应用程序已经开发之后也是如此。它使您不必为数据实体定义具有固定字段的显式类，并且它允许您的应用程序更关心哪些信息适合特定实体实例。

总之，仅使用 JCR 来存储文件可能是矫枉过正 - 听起来您已经拥有存储有关文件的元数据的实体。按照您描述架构的方式，您不会真正受益于 JCR 的任何最佳特性。这让我认为 JCR 根本不适合您当前的架构——您似乎已经自己实现了大部分功能。

于 2014-01-03T15:18:55.907 回答