应用架构设计问题

Question

在设计基于 Java/J2EE Web 的应用程序时，我需要您的建议。以下是它的特点：

1. 纯面向数据库的应用程序（有 10 个表）。数据库是 Oracle。
2. 三种不同类型的界面/屏幕： 2.1 WebSphere Portlet（6 个界面/屏幕） 2.2 手持设备（5个接口/屏幕） 2.3 Web 应用（17 个界面/屏幕）
3. 很少有屏幕只是使用 Crystal Reports 构建的报表。
4. 不涉及太多业务逻辑。

现在我担心的是：

1. 我应该选择 2 层还是 3 层的架构？
2. 我应该使用哪些框架/struts/jsf (MVC)？如果有的话？或者我应该选择没有任何框架的简单的基于 POJO 的编程。
3. 最大的担忧是打包，我的意思是我不想为我想要开发的每三种不同类型的接口复制业务和数据库层。您认为 EJB 是公开 DB/业务层的好选择吗？我该如何处理？
4. 我应该使用任何特定的框架，如 sitemash 作为表示层吗？
5. 我应该使用任何特定的数据库层 JPA/Hibernate 框架还是应该使用简单的 JDBC？

欢迎任何cmets/建议...

BR SC

Answer 1

我应该为 2 层还是 3 层选择哪种架构？

三层：视图、服务和持久性。

我应该使用哪些框架 支柱/jsf（MVC）？如果有的话？或者应该 我选择基于简单的 POJO 没有任何框架的编程。

支柱？不，JSF？不，我推荐 Spring，因为它支持 Web 和门户 MVC 以及契约优先的 Web 服务。

最关心的是包装，我 意思是我不想复制 每个业务层和数据库层 三种不同类型的接口 我想发展。你认为 EJB 将是曝光的好选择 数据库/业务层？我该怎么办 处理这个？

我不会推荐 EJB。我建议使用基于 HTTP 的 Web 服务进行远程处理。

我应该使用任何特定的框架吗 像用于演示的网站 层？

Sitemesh 很好，但它不是表示层。

我会使用 Velocity 模板生成直接的 HTML，然后发回给客户。

我应该使用任何特定的框架吗 对于数据库层 JPA/Hibernate 或 我应该使用简单的 JDBC 吗？

十张桌子？该架构足够小，以至于 JPA 和 Hibernate 对我来说似乎有点矫枉过正。为您的持久层创建一个 POJO 接口，您可以将实现与客户端隔离。从简单开始，如果您决定需要或想要切换它。

Answer 2

我认为第一个答案有很好的基线。我会回应大部分观点，但另外推荐jDBI 用于数据库访问（参见tutorial）；与“原始”JDBC 相比，它很好地简化了处理，但不需要任何映射。