Java 我可以使用什么来代替实体bean？

我想为在线学习编写一个JavaEE应用程序。我想到了这种数据表示：

@Entity
public class Course {
    private String name;
    private String[] instructors;
    private String[] teachingAssistants;
    private GradeBook gradeBook;

    // plenty of methods
}

@Entity
public class GradeBook {
    private GradeBookColumn[];

    // some methods
}

@Entity
public abstract class GradeBookColumn {
    private String name;
    private GradeBookColumnType type;

    // more methods
}

我想要的远不止这些，但你明白了

现在，在EJB3.2规范中，实体bean被删除并替换为JPA实体。我的问题是如何应对这一悲惨的损失。序列化JPA实体不适合我有三个原因：

性能。我需要通过网络推送整个实体及其所有数据。有相当多的数据，可能需要相当长的时间才能全部完成

安全性。如果实体中的所有数据都通过网络传输，则下载该实体的程序可以访问所有数据。但是，我希望只有在用户具有足够权限的情况下才能访问某些数据

写访问。下载数据副本后，客户端应能够对其进行更改。但是，如果进行了更改，这些更改将不会持久化到服务器。当然，我总是可以将实体发送回服务器进行持久化，但我必须通过更慢的上游连接发送所有数据

---

那么，在没有实体bean的情况下，我如何设计这个系统来满足这些要求呢？

我不确定实体bean的丢失是否真的是悲剧，但这是一个意见问题：）

您的桌面上似乎有一个连接到远程服务器的富客户端。您有两个选择：

A.在客户端和服务器之间交换“”对象图。客户端接收一些数据，对其进行修改，然后将其发送回。然后，服务器“”会删除它接收的数据。加载数据时，服务器上有一个事务，合并回数据时有一个事务。为了确保没有冲突，可以对数据进行版本设置

B.你用一个“。在这种情况下，客户端接收到仍然“附加”到会话的实体。对客户端实体的修改将被缓存，并在您调用服务器上的方法时同步

因此，关于您面临的三个设计问题，以下是我的看法：

性能。JPA和其他现代ORM依靠惰性来避免不必要的数据传输：数据按需加载。您可以选择图形的哪一部分可以快速加载或延迟加载。使用选项A，您需要确保在将所有必要的数据发送到客户端之前加载这些数据；如果客户端试图访问未加载的数据，则会出现异常，因为它位于事务之外。使用选项B，我想客户机可以随时延迟加载数据（这值得仔细检查）

安全性。JPA实体应该是业务对象，而不是数据对象。它们可以封装进行必要检查并保留所需不变量的业务方法。换句话说：安全性不是在数据级别处理的，而是在业务逻辑级别处理的。这适用于选项A和B

写访问。使用选项A，您需要发回整个图形并合并它。使用选项B，框架应该以更优化的方式合并缓存的更改

结论：

扩展持久性上下文是为具有长工作单元的GUI应用程序设计的。理论上他们应该解决你的问题。实际上，扩展持久性上下文也有其复杂性（例如，需要使用有状态会话bean）

分离和合并图形的方法更简单，但会带来您提到的性能方面的问题

---

第三种选择是回归传统，以优化性能。在这种情况下，JPA实体只保留在服务器端。您只将真正需要的数据子集传输到DTO中，而不是传输JPA实体。缺点是DTO将大量增加，您将拥有样板代码从JPA实体创建DTO，并从DTO更新JPA实体

我不太明白这是如何满足安全要求的。@tbodt如果您不信任用户，请在业务级别的客户端应用程序中实现安全性；如果您不信任客户端应用程序本身，那么我担心您只剩下选项3，以确保您仅通过网络传输授权数据。