描述你使用的Java Web应用程序的架构？ [英] Describe the architecture you use for Java web applications?

问题描述

让我们分享基于Java的Web应用程序架构！

有许多不同架构的Web应用程序这是使用Java来实现。这个问题的答案可以作为与他们的优点和缺点各种Web应用程序设计库。虽然我知道，答案将是主观的，我们尽量做到客观，因为我们可以和激励我们列出的优点和缺点。

使用您preFER描述你的架构的详细程度。你的答案是任何值的你至少得描述你所描述的架构使用的主要技术和理念。最后但并非最不重要的，的在的我们应该用你的架构？

我将开始...

---

的体系结构概述

我们采用三层架构基于Sun的开放标准，如Java EE，Java持久性API，Servlet和Java服务器页面。

• 持久性


• 商业


• presentation

的层之间的可能的通信流被重新由psented $ P $

 持久性＆LT;  - ＆GT;商业与LT;  - ＆GT; presentation
 

这例如意味着presentation层永远不会调用或执行持久化操作，它总是它通过业务层。此架构是为了满足高可用性的Web应用程序的要求。

持久

执行创建，读取，更新和删除（ CRUD ）持久性操作。在我们的例子中，我们使用的是（ Java持久性API ）JPA和我们目前使用的休眠作为我们的持久性提供和使用它的EntityManager <。 / p>用于

此层分成多个类，其中具有特定类型的实体的每一类的交易（涉及到购物车即实体可能由单个持久性类得到处理）等的 的由一个只有一个的管理的

此外该层还存储 JPA实体这是类似的东西帐户，我的购物等。

商业

这是联系在一起的Web应用程序功能的所有逻辑位于这一层。这种功能可以发起对谁愿意支付使用她/他的信用卡上线的产品的顾客一个货币转移。它也可能只是很好地创建一个新用户，删除用户或计算的一个基于Web的游戏一场战斗的胜负。

这层被分为多个类和每个类都被注解 @Stateless 成为的无状态会话Bean （SLSB）。每个SLSB被称为的管理的和实例的管理者可能会注明如前所述称为类的AccountManager 。

在的AccountManager 需要执行CRUD操作使它对实例 AccountManagerPersistence ，这是适当的呼叫类持久层。两种方法在的AccountManager A草图可以是：

  ...
公共无效makeExpiredAccountsInactive（）{
    AccountManagerPersistence放大器=新AccountManagerPersistence（...）
    //调用持久层
    清单＆LT;＆帐户GT; expiredAccounts = amp.getAllExpiredAccounts（）;
    对于（账户账号：expiredAccounts）{
        this.makeAccountInactive（帐户）
    }
}
公共无效makeAccountInactive（客户帐户）{
    AccountManagerPersistence放大器=新AccountManagerPersistence（...）
    account.deactivate（）;
    amp.storeUpdatedAccount（账户）; //调用持久层
}
 

我们使用容器管理事务，以便我们不必做事务界定我们自己的。什么是引擎盖下发生的基本上是我们首次进入SLSB方法，并提交它，当一个交易（或回滚吧）立即退出该方法之前。这是约定优于配置的例子，但我们还没有需要什么，但默认情况下，必需的，但

下面是如何从Sun的Java EE 5教程介绍了必需的事务属性为企业JavaBeans（EJB的）：

  

如果客户端内运行
  交易调用企业
  Bean的方法，该方法执行
  客户端的事务中。如果
  客户端不与相关联的
  交易，容器启动
  在运行之前，新的事务
  方法。

  
  

所需的属性是隐
  所有的事务属性
  与运行企业bean方法
  容器管理的事务
  划界。您通常不设置
  必需属性，除非您需要
  覆盖另一个事务
  属性。由于事务
  属性是声明，你可以
  后来轻易改变他们。

presentation

我们的presentation层是负责... presentation！它负责在用户界面和建立HTML网页，并通过GET和POST请求接收用户输入显示信息给用户。目前，我们正在使用的是旧的Servlet 的+ Java服务器页面（的JSP ）组合。

的层调用方法在业务层以执行由用户请求的操作和接收信息的网页来显示的管理者的。有时，从业务层接收到的信息是不太复杂的类型为字符串'和 INT egers，并在其他时间 JPA实体的。

利弊与架构

赞成

• 有涉及到这一层做持续性的一种特定的方式只能意味着我们可以使用JPA成别的东西交换，而无需在业务层重新写东西的一切。


• 这很容易让我们交换我们的presentation层成别的东西，而且很可能是我们，如果我们找到更好的。


• 放生EJB容器管理事务边界是很好的。


• 使用servlet的JPA +易（开始用）和技术被广泛应用于并实施了大量的服务器。


• 使用Java EE应该更容易为我们创造与负载均衡高可用性系统和故障转移。这两者我们觉得我们必须具备的。

缺点

• 使用JPA，你可以存储经常使用的查询，命名查询通过使用JPA实体类 @NamedQuery 注释。如果你有尽可能多的相关的持久性类持久性，因为在我们的体系结构，这将小号$ P $垫出来的地点，你可能会发现查询包括JPA实体。这将是难以概述持久性操作，从而难以维持。


• 我们有JPA实体作为我们的持久层的一部分。但帐户和我的购物，并不是他们真正的业务对象？你一定要触摸这些课程，使他们成为这JPA知道如何处理的实体，这样做是这样的。


• 的JPA实体，这也是我们的业务对象，都像数据传输对象创建（ DTO 的）也被称为值对象（VO的）。这导致贫血的域模型随着业务的对象有不同的访问方法没有自己的逻辑。所有的逻辑是由我们的管理者在业务层，这导致了更过程编程风格完成。这不是良好的面向对象设计，但也许这不是一个问题？ （毕竟面向对象是不是唯一的编程范式有交付成果。）


• 使用EJB和Java EE引入了一点复杂性。我们不能单纯的使用Tomcat（添加EJB微容器不是的纯粹的Tomcat的）。


• 有很多的问题，使用servlet的JPA +。使用谷歌有关这些问题的详细信息。


• 由于退出业务层的时候，我们无法加载从被配置为从在需要时数据库加载（使用取JPA实体的任何信息进行的交易被关闭= FetchType.LAZY ）。这将触发异常。返回包含这些类型的字段的实体之前，我们必须要确保调用相关的getter的。另一种选择是使用Java持久化查询语言（ JPQL ），并做了 fetch连接。但是这两个选项都有点麻烦了。



解决方案

好吧，我会做一个（短）之一：

• 前端：挂毯（3旧项目，5新项目）


• 业务层：春


• DAO的：ibatis的


• 数据库：Oracle

我们使用自旋微观事务支持，并在进入服务层，向下传播到DAO通话的开始交易。服务层具有最bussines模型知识，DAO的做比较简单的CRUD的工作。

一些较复杂的查询的东西是更复杂的查询在后端处理性能方面的原因。

在我们的例子中使用Spring的优点是，我们可以有国家/语言相关的情况下，这是一个Spring Proxy类的后面。基于会话的用户，做一个呼叫时正确的国家/语言实现使用。

事务管理是几乎是透明的，回滚上运行时异常。我们使用unchecked异常尽可能。我们用来做检查异常，但引进春天我看到unchecked异常的好处，当你只能处理异常。这避免了大量的样板捕获/重新抛出或抛出的东西。

对不起它比你的文章短，希望你能找到这个有趣的...

Let's share Java based web application architectures!

There are lots of different architectures for web applications which are to be implemented using Java. The answers to this question may serve as a library of various web application designs with their pros and cons. While I realize that the answers will be subjective, let's try to be as objective as we can and motivate the pros and cons we list.

Use the detail level you prefer for describing your architecture. For your answer to be of any value you'll at least have to describe the major technologies and ideas used in the architecture you describe. And last but not least, when should we use your architecture?

I'll start...

---

Overview of the architecture

We use a 3-tier architecture based on open standards from Sun like Java EE, Java Persistence API, Servlet and Java Server Pages.

• Persistence
• Business
• Presentation

The possible communication flows between the layers are represented by:

Persistence <-> Business <-> Presentation

Which for example means that the presentation layer never calls or performs persistence operations, it always does it through the business layer. This architecture is meant to fulfill the demands of a high availability web application.

Persistence

Performs create, read, update and delete (CRUD) persistence operations. In our case we are using (Java Persistence API) JPA and we currently use Hibernate as our persistence provider and use its EntityManager.

This layer is divided into multiple classes, where each class deals with a certain type of entities (i.e. entities related to a shopping cart might get handled by a single persistence class) and is used by one and only one manager.

In addition this layer also stores JPA entities which are things like Account, ShoppingCart etc.

Business

All logic which is tied to the web application functionality is located in this layer. This functionality could be initiating a money transfer for a customer who wants to pay for a product on-line using her/his credit card. It could just as well be creating a new user, deleting a user or calculating the outcome of a battle in a web based game.

This layer is divided into multiple classes and each of these classes is annotated with @Stateless to become a Stateless Session Bean (SLSB). Each SLSB is called a manager and for instance a manager could be a class annotated as mentioned called AccountManager.

When AccountManager needs to perform CRUD operations it makes the appropriate calls to an instance of AccountManagerPersistence, which is a class in the persistence layer. A rough sketch of two methods in AccountManager could be:

...
public void makeExpiredAccountsInactive() {
    AccountManagerPersistence amp = new AccountManagerPersistence(...)
    // Calls persistence layer
    List<Account> expiredAccounts = amp.getAllExpiredAccounts();
    for(Account account : expiredAccounts) {
        this.makeAccountInactive(account)
    }
}
public void makeAccountInactive(Account account) {
    AccountManagerPersistence amp = new AccountManagerPersistence(...)
    account.deactivate();
    amp.storeUpdatedAccount(account); // Calls persistence layer
}

We use container manager transactions so we don't have to do transaction demarcation our self's. What basically happens under the hood is we initiate a transaction when entering the SLSB method and commit it (or rollback it) immediately before exiting the method. It's an example of convention over configuration, but we haven't had a need for anything but the default, Required, yet.

Here is how The Java EE 5 Tutorial from Sun explains the Required transaction attribute for Enterprise JavaBeans (EJB's):

If the client is running within a transaction and invokes the enterprise bean’s method, the method executes within the client’s transaction. If the client is not associated with a transaction, the container starts a new transaction before running the method.

The Required attribute is the implicit transaction attribute for all enterprise bean methods running with container-managed transaction demarcation. You typically do not set the Required attribute unless you need to override another transaction attribute. Because transaction attributes are declarative, you can easily change them later.

Presentation

Our presentation layer is in charge of... presentation! It's responsible for the user interface and shows information to the user by building HTML pages and receiving user input through GET and POST requests. We are currently using the old Servlet's + Java Server Pages (JSP) combination.

The layer calls methods in managers of the business layer to perform operations requested by the user and to receive information to show in the web page. Sometimes the information received from the business layer are less complex types as String's and integers, and at other times JPA entities.

Pros and cons with the architecture

Pros

• Having everything related to a specific way of doing persistence in this layer only means we can swap from using JPA into something else, without having to re-write anything in the business layer.
• It's easy for us to swap our presentation layer into something else, and it's likely that we will if we find something better.
• Letting the EJB container manage transaction boundaries is nice.
• Using Servlet's + JPA is easy (to begin with) and the technologies are widely used and implemented in lots of servers.
• Using Java EE is supposed to make it easier for us to create a high availability system with load balancing and fail over. Both of which we feel that we must have.

Cons

• Using JPA you may store often used queries as named queries by using the @NamedQuery annotation on the JPA entity class. If you have as much as possible related to persistence in the persistence classes, as in our architecture, this will spread out the locations where you may find queries to include the JPA entities as well. It will be harder to overview persistence operations and thus harder to maintain.
• We have JPA entities as part of our persistence layer. But Account and ShoppingCart, aren't they really business objects? It is done this way as you have to touch these classes and turn them into entities which JPA knows how to handle.
• The JPA entities, which are also our business objects, are created like Data Transfer Objects (DTO's), also known as Value Objects (VO's). This results in an anemic domain model as the business objects have no logic of their own except accessor methods. All logic is done by our managers in the business layer, which results in a more procedural programming style. It's not good object oriented design, but maybe that's not a problem? (After all object orientation isn't the only programming paradigm which has delivered results.)
• Using EJB and Java EE introduces a bit of complexity. And we can't use purely Tomcat (adding an EJB micro-container isn't purely Tomcat).
• There are lots of issues with using Servlet's + JPA. Use Google for more information about these issues.
• As the transactions are closed when exiting the business layer we can't load any information from JPA entities which is configured to be loaded from the database when it's needed (using fetch=FetchType.LAZY) from inside the presentation layer. It will trigger an exception. Before returning an entity containing these kinds of fields we have to be sure to call the relevant getter's. Another option is to use Java Persistence Query Language (JPQL) and do a FETCH JOIN. However both of these options are a little bit cumbersome.

解决方案

Ok I'll do a (shorter) one:

• Frontend : Tapestry (3 for older projects, 5 for newer projects)
• Business layer: Spring
• DAO's : Ibatis
• Database : Oracle

We use Sping transaction support, and start transactions upon entering the service layer, propagating down to the DAO call's. The Service layer has the most bussines model knowledge, and the DAO's do relatively simple CRUD work.

Some more complicated query stuff is handled by more complicated queries in the backend for performance reasons.

Advantages of using Spring in our case is that we can have country/language dependant instances, which are behind a Spring Proxy class. Based on the user in the session, the correct country/language implementation is used when doing a call.

Transaction management is nearly transparent, rollback on runtime exceptions. We use unchecked exceptions as much as possible. We used to do checked exceptions, but with the introduction of Spring I see the benefits of unchecked exceptions, only handling exceptions when you can. It avoids a lot of boilerplate "catch/rethrow" or "throws" stuff.

Sorry it's shorter than your post, hope you find this interesting...

这篇关于描述你使用的Java Web应用程序的架构？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！