Question

说，你有一个应用程序列出了你的应用程序中的用户。理想情况下，如果您在Java中编写代码来实现此目的，无论您的UI层是什么，我都会认为您将编写从数据库中检索结果集并将其映射到应用程序对象的代码。因此，在这种情况下，您正在查看您的ORM /数据层执行其操作并创建“用户”对象列表。

假设您的User对象如下所示：

public class User {

      private String userName;
      private int    userid;
}

您现在可以在任何UI中使用此“用户”对象列表。（Swing / Webapp）。现在，想象一个场景，你必须列出userName和一个说，部门或其他的计数，这是一个非常具体的webapp屏幕。所以你正在寻找这样的对象结构：

public class UserViewBean {

            private String userName;
            private int    countDepartments;
}

最简单的方法是编写SQL以在一个查询中检索部门计数和用户名。如果我要编写这样的查询，你会在哪里查询？在你的jsp？但是，如果您在MVC框架中执行此操作，是否将此查询移动到数据层，获取结果集，将其转换为UserViewBean并将其发送到请求范围内的jsp？如果你直接在jsps中编写查询/如果你直接在JSP中使用连接，这不是一个坏习惯吗？

我知道，有些人可能会说，'嘿，你的对象构图错了！如果部门链接到用户，您可能希望在用户对象中创建部门列表' - 是的，我同意。但是，想想这个场景 - 比如，除了这个屏幕之外，我不需要在我的应用程序中的任何其他地方使用此部门计数信息。你是说我从数据库加载我的User对象，我将不得不加载一个依赖对象列表，即使我不会使用它们？您的对象图将与所有关系完整性一起获得多长时间？是的，我知道你有这个原因的ORM，所以你可以获得延迟加载和东西的好处，但我没有使用它的特权。

这里的底线问题是：

如果它仅用于一个屏幕，您会将sqls写入您的JSP吗？ 或
你会构成一个贫血的对象吗？这迎合了你的观点和制作您的业务层返回此这个屏幕的对象 - 只是为了做它看起来有点OOish？ 或
，无论您的屏幕是什么要求，你会组成你的对象，如对象图加载，你会得到的该列表的大小？

这里的最佳做法是什么？

Answer 1

我永远不会把SQL放在JSP中。我会使用Spring MVC或Struts控制器或servlet来包含所有类型的逻辑。它允许更好的错误处理等（当查询失败时，您可以转发到错误页面）。

如果您真的必须这样做，请使用JSTL SQL tags。

Answer 2

如果它仅用于一个屏幕，你会将sqls写入你的JSP吗？

在原型中，就像快速破解一样 - 也许吧。在任何其他情况下，更不用说生产环境 - 从不。

使用适当的MVC框架将业务逻辑与表示分开。

Answer 3

就个人而言，我采取一种简单实用的方法。如果我正在编写屏幕，只显示一个用户列表，其中包含他们的deparment计数，以便整个代码可能是一个页面，我不希望这个代码在任何其他屏幕上使用，我可能只是抛出它所有在JSP中。是的，我知道所有的MVC纯粹主义者都会说，“业务逻辑永远不应该进入JSP”。但除了教条主义的规则，为什么不呢？在这样的情况下会有什么伤害？

如果我发现我有两个屏幕，也许我只需要显示列表，另一个我必须在列表上进行一些额外的处理，那么我肯定会将公共代码拉到一个类中来自两地的电话。

我认为标准应该是：什么产生最易维护的代码？什么是最短最容易理解的？什么产生模块之间的联系最少？等。

我坚决拒绝接受这样的原则：“在某些情况下，这种方法会导致问题，因此永远不会使用它。”如果有时它会导致问题，那么不要在导致问题的情况下使用它。或者更糟糕的是，“有人在一本书中写道，因此不能质疑。”当然，有些规则在99.99％的时间内都是有效的，因此检查这种特殊情况是否异常变得毫无意义。但是有很多规则在51％的时间都是好的，人们从“大部分”跳到“永远”。

Answer 4

我甚至不确定应该使用JSP，而是使用普通的应用程序。如果您真的必须使用它们，请使用MVC模式或将您的逻辑封装在JavaBean中。

Answer 5

查看允许您进行对象操作的JPA，然后将其保存在数据库中

Answer 6

我不会把SQL放在jsp中，因为害怕在将来的维护中忘记它。想想那个维护代码的可怜的人 - 可怜的家伙=你在10个月内或者数据库重组时 - 并且至少把所有SQL放在同一个区域。

在JSP中使用sqls - 最佳实践是什么？

6 个答案: