【发布时间】：2011-08-14 15:45:23
【问题描述】：
将业务逻辑保留在 JSP 之外有什么好处，因为 JSP 主要用于表示？我们仍然看到在 JSP 中编写业务逻辑，所以我需要知道将业务逻辑移出 JSP 可以获得什么好处。
【问题讨论】：
标签： java jsp design-patterns jakarta-ee servlets
【发布时间】：2011-08-14 15:45:23
【问题描述】：
如果业务逻辑与表示逻辑分离，则更好地重用和维护 Web 应用程序。
假设我有 3 个 JSP 页面，每个页面都需要执行一些通用的业务逻辑。如果我把业务逻辑放在JSP页面里面，就会有重复的代码。
【讨论】：
只是为了补充其他同行发布的充分理由，特别是关于“业务逻辑应该从 JSP 中移出”。
简而言之，在工作中，我们有很多 JSP，其中业务逻辑已经结束，而且看起来非常混乱。从会话/请求中获取对象并执行某些检查是有逻辑的。一个简单的例子是根据 JSP 中的特定条件构建不同的页面标题。
这个逻辑最终是如何移动的，是引入一个 Page Builder/Composer 对象，该对象包含构建特定页面所需的所有细节，并检查和设置页面 bean 对象中的所有正确字段。然后根据请求设置此页面 bean 对象，例如这意味着您之前在 JSP 上拥有的所有逻辑现在都已移至页面构建器/编写器对象，然后最重要的是您可以编写 单元测试 进行测试！如果在页面 bean 中设置了正确的值。
final SimplePageBuilder pageBuilder = new SimplePageBuilder(object1);
request.setAttribute("TestBean", pageBuilder.buildPage());
buildPage 方法将返回页面 bean 对象，并且在 jsp 中一个简单的示例 getTitle 将简单地返回标题（易于阅读，因为逻辑是抽象的）。
【讨论】：
我不确定，但这可能是原因：
出于可重用性目的。
Jsp 应该只用于 演示目的和我们的 html 设计师，后来设计 页面不知道java编码会不舒服。 并在 servlet 中编写所有业务逻辑让代码 reusable.and 用于在 jsp 页面中编写业务逻辑 还有其他一些方法，比如使用 scriplets.so 为什么要做这项工作 更少的利润和额外的工作。
现在，如果我们使用 jsp 页面进行业务逻辑，那么 scriptlet 将更多地位于 JSP 页面内部，从而导致 维护成本高。业务单元的servlet单独声明将 避免以上所有。
【讨论】：
这是Separation of Concerns 设计原则的典型应用。
通过分离关注点，即为每个关注点创建单独的逻辑单元（主要是类），您可以减少更改任何特定的原因的数量
SoC 的另一个好处是减少这些单元的平均尺寸和复杂性。这反过来又使您的软件更易于理解和更改。
此外，具有小的逻辑单元使它们更容易进行单元测试，更容易在集成测试中模拟，并且更容易在实现更改后修复测试。
【讨论】：
-
@Codemwnci 介意我将您的评论纳入答案吗？
-
理论上你可以把你的表现层换成别的东西。或者通过 Web 服务公开功能。
-
请做，这就是我评论的原因，而不是发布答案。 +1 以获得好的答案。
MVC 的主要好处是您可以拥有多个视图以及干净和分离的架构&Simplicity
可重用性
假设明天您需要在桌面应用程序上运行相同的应用程序。然后你可以改变视图。
可测试性
您可以对服务方法进行单元测试，但不能简单地从视图中对逻辑进行单元测试。
可维护性
Service方法的代码很容易理解，我们也可以修改/发布服务api，方便维护
版本能力
如果您使用服务 API 代替逻辑视图，您可以为您的 API 提供版本并维护与问题/更新相关的标准文档
另见
【讨论】：
我会为这里发布的所有非常好的理由再添加一个理由。
客户端技术一直在变化。用户不想通过桌面、浏览器或移动应用程序访问；他们想一直使用它们。因此，如果您将业务逻辑嵌入到一种用户界面技术中，您可能不得不在所有其他技术中复制它。这不利于维护、可重用性和添加新业务逻辑。
您不希望仅仅因为您决定更改 UI 技术而重新编写您的应用程序。
这对安全性也更好。如果业务逻辑下到浏览器，用户就有机会看到代码并弄清楚你在做什么。
所以你最好把业务逻辑放在服务器端。
【讨论】：
- 它变得可重用（既可用于其他应用程序，也可用于不同的视图（例如 JSON API））
- 它从设计师手中夺走了它（所以它不会妨碍他们，也不会意外破坏它）
【讨论】：