我有一个应用程序，可以将客户发送到另一个站点来处理付款。客户之外的另一个站点在我们的服务器上调用一个页面，以让我们知道付款的状态。被调用页面会检查付款应用程序提供的参数，并检查我们是否知道该交易。然后，它更新数据库以反映状态。这一切都无需与客户进行任何互动即可完成。

我个人选择将此功能实现为JSP，因为将文件拖放到文件系统中比编译和打包文件然后将条目添加到配置文件中要容易得多。

解决方案

JSP应该用于表示层，用于业务逻辑的servlet和后端(通常是数据库层)代码中。

我不知道我们为什么不能按照描述使用JSP(无论如何，它都会被容器包含到servlet中)，但是我们是对的，首选方法是首先使其成为servlet。 。

是的，这应该是一个servlet。 JSP可能更易于开发，但servlet则更易于维护。试想一下，必须在6个月内修复一些随机的错误并尝试记住它是如何工作的。

JSP本质上是标记，可通过servlet容器自动将其编译为servlet，因此在这两种情况下都将进行编译步骤。这就是为什么支持JSP的Servlet容器必须具有完整的JDK而不是仅需要JRE的原因。

因此，使用JSP的主要原因是减少呈现页面所需的代码量。如果不必呈现页面，则servlet更好。

如今，大多数Java应用程序都是基于MVC模式构建的。
在控制器端(servlet)中，我们可以实现业务逻辑。 servlet控制器通常将请求转发到一个jsp，它将生成实际的html响应(MVC中的View)。
目的是要分离关注点...关于该主题，已经编写了成千上万的书籍。

JSP：将数据呈现给用户。这里没有业务逻辑，当然也没有数据库访问权限。

Servlet：处理来自表单或者特定URL的输入。通常，人们会在Servlet之上使用Struts / Spring之类的库来清理程序。无论如何，Servlet都应该仅验证输入的数据，然后将其传递到后端业务层实现(可以对测试用例进行编码)。然后，它将结果值放在请求或者会话上，并调用JSP来显示它们。

模型：一种数据模型，其中包含网站处理的结构化数据。 servlet可以接受参数，将其放入模型中，然后调用业务层。然后，该模型可以与后端DAO(或者Hibernate)交互以访问数据库。

任何不重要的项目都应实现MVC结构。当然，对于琐碎的功能来说，这是过高的。在情况下，我将实现一个称为DAO的servlet，以更新状态等，或者所需的其他内容。

JSP是编写Servlet的快捷方式。实际上，它们在编译之前已转换为servlet Java代码。 (我们可以在我不记得这个名字的tomcat子目录下检查它)。

要在Servlet和JSP之间进行选择，我使用一条简单的规则：如果页面包含的HTML代码比Java代码更多，请使用JSP，否则只需编写Servlet。通常，这大致可解释为：使用JSP进行内容表示，使用servlet进行控制，验证等。

同样，由于它使用简单的Java类语法，因此更易于在servlet中组织和构造代码。 JSP倾向于更加单一，尽管有可能在那时内部创建方法。

第一次运行JSP时，会将其编译为Servlet。这意味着它们之间没有真正的运行时差异。

但是，大多数人都有将servlet用于控制器并将JSP用于视图的传统。由于控制器只是Java类，因此我们可以从所有IDE中获得完整的工具支持(代码完成等)。与JSP相比，这提供了更好的质量和更快的开发时间。一些更高级的IDE(想到的是IntelliJ IDEA)具有对JSP的强大支持，使该参数过时了。

如果我们要创建自己的框架或者仅使用简单的JSP进行构建，则应该继续使用JSP。性能没有任何区别，如果我们觉得JSP易于编写，那么请务必继续。

在MVC体系结构中，servlet被用作控制器，而JSP被用作视图。
但是两者在技术上是相同的。 JSP将在编译时(例如在JDeveloper中)或者在首次访问时(例如在Tomcat中)转换为servlet。
因此，真正的区别在于易用性。我很确定我们将很难使用servlet渲染HTML页面。但是与常识相反，我们实际上会发现，即使在JSP内甚至是相当复杂的逻辑，也都可以很容易地编写代码(也许借助一些准备好的帮助程序类)。 PHP的人总是这样做。因此，它们陷入了创建意大利面条代码的陷阱。
因此，我对问题的解决方案是：如果我们发现使用JSP编写代码更容易并且不会涉及太多代码，请随时使用JSP编写代码。否则，请使用servlet。

同意以上关于JSP和Servlet之间差异的所有观点，但是这里有一些其他注意事项。你写：

I have an application that sends the
  customer to another site to handle the
  payments. The other site, outside of
  the customer, calls a page on our
  server to let us know what the status
  is of the payment. The called page
  checks the parameters that are given
  by the payment application and checks
  to see whether the transaction is
  known to us. It then updates the
  database to reflect the status. This
  is all done without any interaction
  with the customer.

应用程序正在使用另一个应用程序的支付服务。解决方案很脆弱，因为如果其他应用程序中的支付服务发生更改，则会中断JSP页面。或者，如果我们想更改应用程序的付款政策，则必须更改页面。简短的答案是应用程序应该通过Web服务使用该应用程序的支付服务。 Servlet和JSP页面都不适合放置消费逻辑。

其次，沿着这些思路，最近几年大多数servlet / JSP页面的用法都放在了诸如Spring或者Struts之类的框架的上下文中。我建议使用Spring，因为它可以为我们提供从服务器页面到Web服务网关逻辑再到DAO的完整堆栈。如果我们想了解Spring的基本原理，我建议我们使用Spring in Action。如果我们需要更好地理解如何对用Java(或者C＃)之类的语言编写的企业体系结构进行分层，则建议使用Fowler的企业应用程序体系结构模式。

我知道这不是当今流行的答案，但是：当我从头开始设计应用程序时，我总是使用JSP。当逻辑不平凡时，我将创建普通的Java类来执行从JSP调用的繁琐工作。我从不理解应该使用servlet的观点，因为作为纯Java类，它们更易于维护。 JSP可以轻松地调用纯Java类，当然，普通Java类与任何servlet一样可维护。在JSP中格式化页面更加容易，因为我们可以将所有标记置于行内，而不必编写一堆println。但是，JSP的最大优点是我们可以将它们放在目录中，并且可以直接访问它们：我们无需费心在URL和类文件之间建立关系。通过使每个JSP都可以通过一个安全检查来轻松地处理安全性，该检查可以是单个调用语句，因此无需将安全性放在调度层中。

我看到使用servlet的唯一原因是，如果我们需要URL与生成的执行类之间的复杂映射。就像，如果我们想检查URL，然后根据会话状态或者类似情况调用许多类之一。就我个人而言，我从来都不希望这样做，而且我所看到的做到这一点的应用程序往往很难维护，因为在开始进行更改之前，我们必须弄清楚真正执行的代码是什么。

有2条非常简单的规则：

• 我的推定正确吗？
• 是否有真正的理由在JSP上使用servlet？

相关问题：

• 那些原因是什么？

在Java Servlet中，HTML标记嵌入在Java编码中。
在JSP中，Java编码嵌入HTML标记中。

对于大问题的大型应用程序，由于无法在Java编码中嵌入更多html标签，因此servlet难以读取，理解，调试等。因此我们使用jsp。

感谢和问候，
西瓦库马尔

列表数量不匹配

列表数量不匹配

列表数量不匹配