Java iBatis是动态SQL查询的正确选择吗？

我面临以下设计问题：

• 将有几个准备好的SQL语句，其中where子句包含定义的约束，其中的值将是动态的，基于用户输入
• 此外，还需要一些SQL语句，这些语句可能会非常复杂，但最终生成的SELECT子句）仍然非常简单

据我所知，iBatis将符合这些要求

• 现在，如果用户（通过UI）会影响完整的查询构造，并临时进行查询，那么会发生什么情况

准备好的语句不能作为一个动态的WHERE子句来执行，我们甚至可能在SQL函数中内置聚合子句，甚至子选择

---

考虑到所有这些，您是否仍会选择iBatis，或者根据上述要求进行其他定制开发，作为最佳体系结构？

我会投票支持iBatis。我一直认为，如果要执行复杂的SQL查询（特别是大量的联接和子选择），并且结果集很小，那么这是最好的选择

---

当您使用iBatis时，您对SQL有更多的控制，并且还可以帮助您与现有/遗留数据库集成。

iBatis在这种情况下可以工作。我们使用了与您描述的完全相同的场景，使用iBatis根据用户从UI中的选择创建动态的临时查询。随着页面间可用的用户元素数量的增加，复杂性也随之增加，但这是可行的

Hibernate是一个功能齐全的ORM，这是另一个明显的选择，但使用起来更复杂。以下是一些帮助链接：

所以我会选择iBatis作为第一选择，或者选择Hibernate作为解决方案。我认为，由于复杂性，定制解决方案很容易变成大量复杂的嵌套代码，除非您首先真正考虑整个设计。当然，假设需求不会随着您的行为而改变

---

我觉得iBatis可以让您更好地组织工作中的sql代码，并在设计中提供灵活性，以代替将来的更改。伊姆霍

最新版本的iBatis（MyBatis）允许我们使用强大的基于OGNL的表达式来构造动态查询。iBATIS最强大的功能之一始终是其动态SQL功能

以myBatis为例。它是iBatis的最新版本。iBatis的开发已经停止（我相信）。在某个时候（由于我不知道的原因），这个项目从Apache转移到了Google，名字改成了myBatis。对不起，我当然是指myBatis。。。