Am I in tier leakage anti pattern? What should I do?

Question

I was asked to add a module to existing system. While studying the structure, I found something 'weird'. The system is struts1 based.

In some jsp, I found there are some DAO call to return entity object. In most JSP pages, there is a <app:validate> tag, which would make call to DAO to check access rights, and would redirect to the login page if not permitted. There is an accessDA object, but it does more than data fetching, it also does some access right checking.

My questions are:

1. Does calling out DAO in view lead to tier leakage?
2. Is the app tag implementation a good practise (or should it do checking at action class instead of at view)?
3. Is the accessDA too fat?
4. Should my new module follow the existing structure?

Answer 1

In a typical MVC usage, there should be a clear Separation of Concerns . Meaning, Model, View and Controller part should be decoupled. Let me answer your questions

1. calling out DAO is it lead to tier leakage

Yes. Ideally and DAO calls should be there in action/handler class. The data thus obtained is put in request/session to be picked up later by view rendering tier.

2.the app tag implementation, is it a good practise?(or should it do checking at action cla ss instead of at view.)

There should not be a DAO calls on every access right check. The access rights should be cached as the user login and same should be checked on subsequent requests using the aforementioned tag. So here, not direct violation though but not a good practice.

3.is it the accessDA too fat?

Yes. It appears so.

4.should my new module follow the existing structure?

Having made the above observations, I would advice against it.

Answer 2

1) IMO yes, but: it's not a leaky abstraction as such, precisely because it's in a tag. Tags exist to abstract implementation details from the view. It's also arguable that doing the access lookup in the action makes the action responsible for something that's relevant only to the view layer.

Another issue with encapsulating the data access in the tag itself is that if there are many uses of the tag on the page there may be more data access than necessary, slowing response time. A clever tag could mitigate this by caching values, or caching may be implemented at a deeper level.

2) A tag like that should be acting against the current user object, which should have encapsulated the user's rights already (probably on login). That said, it may not be sufficient to use cached values to determine access rights if those rights may change during a user's session.

3) I don't know; without knowing more details IMO that's impossible to answer.

4) Depends. Doing the same thing multiple ways can lead maintenance nightmares.

If there's an effort to re-structure the application according to best practices, then yes, new development should follow better patterns. If there isn't, IMO it's more confusing to introduce multiple ways of doing the same thing, and makes it more difficult for those who follow because they then need to decide which way to do something, determine if there's a functional difference between the different ways, and so on.