【发布时间】：2010-12-22 07:42:02
【问题描述】：
为什么我们不应该将 JSP 用于业务层？
是性能吗？ 或者这只是一个好习惯？ 当然，可重用性是一个原因。除此之外，我们应该将 jsp 用于业务层还有什么杀手锏？
【问题讨论】：
标签： jsp
【发布时间】：2010-12-22 07:42:02
【问题描述】：
通常的原因是关注点分离。您应该在不影响业务层的情况下轻松修改演示文稿。
【讨论】：
-
假设我不经常改
-
成为习惯的创造者，遵循最佳实践总是好的，因为它们已经融入了我们
可重用性和可维护性是一些大问题。
考虑以下情况；
想象一下你想创建一个 iPhone 应用程序的版本，你有 将所有业务逻辑移植到 iPhone，现在让我们有一个 Eclipse RCP 前端 应用程序和基于 Flash 的；然后与基于 Python 的系统集成。
因为业务逻辑和 演示文稿在同一个文件中， 有创意的 Web 开发人员必须 如果他打算学习一些Java 创建最好的界面 破坏应用程序。
【讨论】：
如果您要制作超过 5 页的应用程序，那么混合逻辑和演示可能会让您的生活更加困难。但这是我的一个不受欢迎的观点 - 对于小型应用程序（甚至是中型应用程序），只有一个“了解他的代码”的开发人员，可以将 JSP 用于业务逻辑。它可能是放置在/action/ 文件夹中的 jsps，稍后会重定向到演示文稿，或者它可能是来自请求的相同 jsps。我有一个例子——在我的开发实践开始时，我制作了一个几乎完全基于自发布 jsps 的基于 Web 的策略游戏。那是5年前的事了。几周前，我查看了我的代码库，我可以理解所有内容。因此，如果您刚刚开始，并且您不想从一个会让您的学习曲线更加陡峭的大框架开始，并且您不希望您的项目非常大或商业化（旁注：我的商业化了在某一时刻），然后随意将 jsps 用于业务逻辑，但请注意这在常见情况下不是一个好的做法。
【讨论】：
几个原因：
- 可重用性：您不能重用脚本。
- 可替换性：您不能将 scriptlet 抽象化。
- OO 能力：不能使用继承/组合。
- 可调试性：如果 scriptlet 中途抛出异常，你得到的只是一个空白页。
- 可测试性：scriptlet 不可单元测试。
- 可维护性：每个 saldo 都需要更多时间来维护混合/杂乱的代码逻辑。
还有更多，但归根结底，scriptlet 是一种不好的做法。
使用JSTL 和EL，您可以在表示层做很多事情。如果您发现它们中的任何一个都无法实现，并且您不得不获取 scriptlet，那么代码逻辑最终属于 real Java 类。你可以使用Servlet类来控制/预处理/后处理请求，你可以使用Filter类来过滤请求，你可以使用DAO类来做数据库交互，你可以使用Javabean类要存储/传输/访问数据，您可以将Domain 类用于业务逻辑，您可以将Utility 类用于静态工具。
【讨论】：
-
为了什么值得，大约半年后我已经发布了关于这个主题的更详细的答案：stackoverflow.com/questions/3177733/…