Hi Scott,
From my perspective, I always saw the AuthenticationDao as just that... a pluggable interface for authentication data access (i.e. in-memory, jdbc, ldap, etc.)
I personally dont see this interface at a Service Layer level?
The AuthenticationProvider err.. provides a layer ontop of the actual authenticatonDao, so maybe I am missing something.
I am all for refactoring / renaming, however I would be a little careful since 0.8.3 to 0.9 was a little API change for Acegi users... albeit minor changes.
I would think that renaming the AuthenticationDao would be less of a change, compared to the ContextHolder changes.
I think the API needs to stabilize... its less shocking for users :)
I do kinda see what you mean Scott... having a service layer implement a DAO... normally doesnt sit well with developers ;)
Although I am not sure if your situation is common (3 authentication dao's to build up the user's roles?) Just curious why?
So if its a vote... mine would be 'no'
** Although I do like that we are all trying to keep the code clean and concise. Good stuff.
Cheers,
Mark
On 11/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi all,
I chatted with Ben briefly about this last night and he suggested I
bring it up on the list for others to chime in...
I'd like to propose renaming the AuthenticationDao interface to
AuthenticationService prior to 1.0.0.
Why? It's ultimately just a naming thing, but my feelings are that
Acegi shouldn't delegate authentication to an interface that encourages
developers to bypass the business service layer and go straight for the data
access layer. And generally, an application's DAOs shouldn't be executing
business logic (like role construction) or tapping multiple DB connections,
web services and other potential authentication & authorization stores.
For example, the app I'm currently working on needs to reference
three different DAOs during authentication to build the user's ultimate list
of roles. Clearly this multiple-datasource operation needs to occur within
the boundaries of a distributed transaction, so I did just that by building
an AuthenticationServiceImpl that implements AuthenticationDao. This is all
well and good, but when I first approached this problem I had to get over
the fact that my *service* needed to implement a *dao* interface. This may
not be so obvious to newcomers already in close combat with Acegi's
sophisticated terminology and design.
The downside of changing AuthenticationDao to AuthenticationService
(sorry, "AuthenticationManager" may be consistent with Spring's nomenclature
but it's already taken) is that a lot of API code, documentation and example
XML files will need to be changed. Users will also have to do the same.
Would it be worth it? I don't really know, but the argument could
be made for making this change now, before 1.0.0 is out, since it's such a
core part of Acegi's API. I also believe that it will make the class
heirarchy easier to understand and explain, which I think is a challenge
that Acegi already faces.
I'd be willing to make these changes - Eclipse can easily handle the
renaming and dependancy changes, and updating the JavaDoc, reference guide,
XML files, etc. is mostly just search-and-replace and validation. But I
want to know what everyone thinks first.
Thanks,
Scott
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
