在 EJB BMP 中实现高级查找（过滤）的常见做法是什么？
我正在使用 Struts 1.3.8 + EJB 2.1 开发一个项目。
我有几个导航jsp（有某种包含实体的表）。在导航菜单中，用户可以为每个表列选择过滤条件。他在下拉列表中选择一个过滤运算符并输入条件值。
列有不同的类型，包括字符串、数据、整数等。
现在我使用一个简单的 Condition 类，它封装了三个值（列名称、运算符和值）。
在操作 servlet 中，我通过调用 Finder 方法将条件发送到适当的 EntityBean。
Finder 方法使用 QueryBuilder 类，它生成 SQL 查询（实际上它只是添加 WHERE 条件并验证数据）。
我不喜欢这个方案有几个原因。
首先，它在 QueryBuilder 中使用原始 SQL，因此我必须实现数据验证以防止 SQL 注入。
其次，表示层和业务层变得高度耦合（表示层必须知道数据库中使用的列名称，或者 QueryBuilder 必须知道表示中使用的列名称）。
我只能使用EJB 2.1版本，并且实体bean必须是BMP。
我想知道是否有一些好的实践来实现上述机制，或者只是想看看一些关于我的问题的有用建议。
谢谢你的帮助。
I'm developing a project using Struts 1.3.8 + EJB 2.1.
I have several navigation jsp's (there are some kind of tables containing entities). In navigation menu user can choose a filter condition for each table column. He chooses a filter operator in a dropdown list and inputs condition value.
Columns have a different types including string, data, integer etc.
Now I'm using a simple Condition class, which incapsulates three values (column name, operator and a value).
In action servlet I'm sendind Conditions to the appropriate EntityBean by calling Finder method.
Finder method uses QueryBuilder class, which generates SQL query (practically it just adds WHERE conditions and validates data).
I don't like this scheme for several reasons.
Firstly it uses a raw SQL in QueryBuilder so I must implement data validation to prevent SQL injections.
Secondly presentation and business layers became high coupled (presentation must know column names using in DB, or QueryBuilder must know column names using in presentation).
I can use EJB 2.1 version only, and entity beans must be a BMP.
I want to know if there some good practice to implement above mechanism, or just to see some helpful suggestions about my problem.
Thank you for you help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先解决您的问题：
1) PreparedStatement 应该在后台使用，因此您无需担心这一点。
2) 查看 Fast Lane Reader，然后编写一个用于过滤的 API使用列名称。在这种情况下，您必须自己编写 SQL 并使用上面提到的PreparedStatement
，但一个问题是有多少用户、每次调用的成本有多高以及您有多少内存。我最近编写了一个应用程序，可以为用户提取数万条记录，并且可能需要超过一分钟的时间来刷新。幸运的是，我的用户群非常小，所以我选择了前端过滤。这是初始负载，用户体验会好得多。我也不需要始终显示最新信息。
有关性能的问题，请参阅Entity Bean finder 方法与 DAO？。
To address your concerns first:
1) PreparedStatement should be used in the background so you dont need to worry about that.
2) Look at the Fast Lane Reader and then write an API for filtering instead of using the column names. In which case you would have to write SQL yourself and use the above noted PreparedStatement
But one question would be how many users, how expensive is every call and how much memory do you have. I recently wrote an app that pulls tens of thousands of records for the user and can take longer than a minute to refresh. Fortunately my user base is very small so i opted for frontend filtering. Its an initial load and from that the user experience is much better. I also didnt need to show always up to date information.
See Entity Bean finder methods VS DAO? for a question on performance.