I’'m very confused with current implementation.
I was trying to write my custom UserProvider but it seems org.jivesoftware.messenger.user.User object is loading its properties via sql.
So, it is insuffcient to implement a UserProvider. Could somebody explain me why User object have logic inside it? Isn’'t jive messenger uses User object as DTO? It seems this is an anti-pattern.
thnx,
evrim.
Hi,
At DTO is something is physically transferred between tiers (serialized) usually containing a graph of objects - an attempt to mitigate the number of network calls (rmi or iiop) to remote objects. That may not be the definitive definition, but I think it captures the essence.
According to my understanding, the User object is not a DTO, it is a first class object in the system. This is the java doc for the User class
Encapsulates information about a user. New users are created using {@link UserManager#createUser(String, String, String, String)}. All user properties are loaded on demand and are read from the ``
jiveUserProp
database table. The currently-installed {@link UserProvider} is used for setting all other user data and some operations may not be supported depending on the capabilities of the {@link UserProvider}.
However UserProvider only supports a subset of user attributes i.e. username, name, password, email. If you want to extend this you can of course. It would be nice have a user interface like IUser to make this kind of customisation easier, but you can always extend the User object and override the bits you need.
The User object is certainly not an example of an anti-pattern. It is a perfectly legitimate and recognised implementation technique.
Hope that helps,
Conor.
Facade pattern is good for persistence access. Accessing database inside User object, for me just complicates things like Exception Handling, Performance Monitoring, Transaction Management, Container Managed Declerative Security. What about changing the persistence mechanism to something like prevalence or db4o? It seems there will be problems in future. Just want to warn. This is my experience with jive messenger code.
The database logic used in Jive Messenger is currently very simple and will remain so for probably just about everything except an eventual logging framework. To us, that means that using straight JDBC is a better fit than a heavier persistence layer that others may not be familiar with.
Regards,
Matt
i would suggest db4o then its 1000 times faster than jdbc, simpler than jdbc and one can write native java queries and eclipse will show you red-cross if your queries are broken. I’'m not experienced though, its a challange for us to integrate db4o into j2ee or spring.