Restricting access to mutators, DAOs

[jtravis_hyperic]

2 topics:

1) In all new development, I strongly suggest we restrict access to
POJO mutators. It makes it very obvious who can manipulate the POJOs
-- and that should only be the manager classes. By making the
mutators package-private, we are guaranteed that only the correct
objects have access to making changes.

2) I thought we all agreed that all DAO methods should be package
private? This ensures that a transaction is setup since calls will
need to be made through the Manager layer. In addition, if we decide
to add security checks later, this should happen at the manager layer
as well.

Does anyone disagree?

-- Jon

[admin]

1) Agreed

2) Didn't realize that we had this agreement already. I definitely
agree with it conceptually, but not sure if practically this can be
enforced 100% if there are some managers who need to call into DAOs
of other subsystems. In such cases, I suppose then we can introduce
accessors through the appropriate manager APIs, but wonder if that
creates a whole lot of additional work, because you'd have to create
another session bean from whatever session bean (or maybe even
message driven bean) you are in just to access the DAO. I suppose if
we leave room to bend the rule when needed, then we can go through
the DAOs and just change the accessibility for all of the APIs and see.

Charles

[jtravis_hyperic]

I'm somewhat OK with having finders in DAOs be publicly accessible --
mostly because it's unlikely that we'll ever 'not' be in a
transaction (save test code which is have been incorrectly using
DAOs.) Mutators in DAOs (save, evict, etc.) should definitely not be
public -- it's the job of the managers to do those things.

Note, if we actually made all the methods in the DAO protected, it
would be impossible for programmers writing test code to do the wrong
thing. I like that mentality -- making it impossible for the
programmer to do the wrong thing.

-- Jon



On Nov 16, 2006, at 10:47 AM, Charles Lee wrote:

> 1) Agreed
>
> 2) Didn't realize that we had this agreement already. I definitely
> agree with it conceptually, but not sure if practically this can be
> enforced 100% if there are some managers who need to call into DAOs
> of other subsystems. In such cases, I suppose then we can
> introduce accessors through the appropriate manager APIs, but
> wonder if that creates a whole lot of additional work, because
> you'd have to create another session bean from whatever session
> bean (or maybe even message driven bean) you are in just to access
> the DAO. I suppose if we leave room to bend the rule when needed,
> then we can go through the DAOs and just change the accessibility
> for all of the APIs and see.
>
> Charles

[admin]

Agreed. So, what do we want to enforce here?

- Mutators be protected?
- Finders can be public?

I guess I'd rather not have a rule that we'd change when the
situation requires. So, should we just leave the finders out of this?

Charles

[jtravis_hyperic]

The only concern I have with finders being public is this:

There is a dichotomy between when you want to be able to access
finders -- in context of permissions, and permissions aside.

The DAOs have no permission checking, whereas the managers do. If we
want to preserve permissions up & down the full stack correctly,
we'll probably want to route things entirely through the managers.

I think the tradeoff is this:

1 - Public DAO finders: Save typing, since you won't have
passthroughs in the manager
2 - Private DAO finders: Allow access control, single way for
accessing types, eliminates the possibility of tests using them &
doing stuff outside transactions.

-- Jon




On Nov 16, 2006, at 11:06 AM, Charles Lee wrote:

> Agreed. So, what do we want to enforce here?
>
> - Mutators be protected?
> - Finders can be public?
>
> I guess I'd rather not have a rule that we'd change when the
> situation requires. So, should we just leave the finders out of this?
>
> Charles