Why to Use Life Ray User object instead of CUstom Bean

I am using Liferay portal 6 , please tell me Why to Use Life Ray User object instead of CUstom Bean

public class UserBean {

private String firstName;
private String lastName;
private 开发者_运维百科String middleName;
private long userId;
private String screenName;
}


The way we are getting User from Liferay
User userObj = UserLocalServiceUtil.getUserById(userId);

BeanUtils.copyProperties(UserBean, userObj);

I am new to LifeRay portal properties , so please excuse if my questions are dumb

My question is , if i have my User Object (UserBean ) then why do we need get access to Liferay User??

---

Good question. What are you doing with Liferay users? Are your users stored somewhere other than Liferay? Are you maintaining two sets of users, one in Liferay and one somewhere else? BeanUtils.getProperties() uses reflection, so you may want to consider a different method for adapting regardless of why it's being done.

I'm trying to read between the lines and figure out why you would want to do something like that. Could you put the scenario in context for me? Forgive me for being ignorant, but only reason I can come up with is that you want to be able to deploy your code on more than one portal platform. Is that an accurate assessment?

If that is an accurate assessment, then I can see wrapping the Liferay User object and you would probably want to adopt the adapter pattern. Otherwise, if the Liferay User object already has the fields and methods that you're putting on your UserBean class, I'm not sure why you would want to wrap it.

If the use case is not deploying to multiple portal platforms, could you share what the use case is? I'm hard pressed to find a reason you would want to wrap the Liferay User in your own UserBean class. Actually, I can only come up with reasons why you shouldn't do that. I can see how you could be concerned that your company would switch platforms at sometime in the future. That's a legitimate concernt, but it's uncertain. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed.