Java - Ibatis - mySQL 具有基于角色的动态查询
我在前端使用 Java - Ibatis 和 mySQL 以及 Flex/Flash。 我有一个要求,即能够根据用户角色动态地将 creterias 和表添加到查询中。 这是一个示例
相同的对象调用相同的 SQL,但根据角色的不同结果不同
角色 1:对员工的完全访问
SELECT *
FROM Employee A
角色 2:对员工的有限访问
SELECT *
FROM Employee A
, SECURE_LIST B
WHERE B.EmployeeID = A.EmployeeID
AND B.ROLE_ID = 'ROLE'
我可以使用动态 SQL
SELECT *
FROM Employee A
<isNotEmpty property="ROLE" >
, SECURE_LIST B
WHERE B.EmployeeID = A.EmployeeID
AND B.ROLE_ID = #ROLE#
</isNotEmpty>
其他想法吗?
I'm using Java - Ibatis and mySQL with Flex/Flash on the front-end. I have one requirement that is to be able to dynamically add creterias and table to a query depending on the user role. here is an example
Same object calling same SQL but different result based on role
Role 1 : Fully Access to employees
SELECT *
FROM Employee A
Role 2 : Limited access to employees
SELECT *
FROM Employee A
, SECURE_LIST B
WHERE B.EmployeeID = A.EmployeeID
AND B.ROLE_ID = 'ROLE'
I could use Dynamic SQL
SELECT *
FROM Employee A
<isNotEmpty property="ROLE" >
, SECURE_LIST B
WHERE B.EmployeeID = A.EmployeeID
AND B.ROLE_ID = #ROLE#
</isNotEmpty>
Other ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
比创建 DAO 简单一点,但仍然可以灵活地添加其他联接或其他 where 子句元素,而无需在每个参数映射中包含角色
A little simpler than creating DAOs but still providing you the flexibility to add other joins or other where clause elements without having to include role in every parameter map
在查询中使用角色的问题是,您必须将其作为参数提供给可能每个查询的查询。 当您需要向查询提供参数时会发生什么? 您还需要向这些参数类/映射添加角色。 一切都有点乱。
我会退后一步,定义您的 DAO:,
然后创建两个实现:
这种方法的一个优点是,如果特定角色不应该使用某些方法,您可以选择抛出一些安全违规异常。
现在,我没有足够的细节来评论如何将其插入到应用程序的其余部分。 您可能正在使用 BlazeDS,在这种情况下,我建议使用 Spring 与 BlazeDS 集成,这将打开依赖注入作为一个选项。
或者,您可以使用简单的工厂方法(基于角色)来获取正确的 DAO。
毫无疑问,根据您的配置,还有其他方法可以插入它。 我认为上面的内容比你提出的要干净得多。
The problem with using role within the query is that you have to then supply it as an argument to the query for possibly every query. What happens when you need to supply arguments to the query? You'll need to add role to those parameter classes/maps too. It's all a bit messy.
I'd take a step back and define your DAO:
and then create two implementations:
One advantage of this approach is that if certain methods shouldn't be used by a particular role you have the option of throwing some security violation exception.
Now how you plug that in to the rest of your application is something I don't have enough detail to comment on. You might be using BlazeDS in which case I'd suggest using the Spring integration with BlazeDS, which will open up dependency injection as an option.
Alternatively you could use a simple factory method (based on role) to get the correct DAO.
There are no doubt other ways to plug this in depending on your configuration. I think the above is a lot cleaner than what you're proposing though.