How should I create custom login functions

I am creating a Rails application and I want to have user registration / login. I also need to have other fields in the user model like address (street, city, country), facebook info, twitter info, last login time ... etc.

From a design point of view, is it better to have a User model very lightweight and only have username / password / email and leave other fields for a separate model like "profile", or is it better to mix these things together?

I like performance the most.

Thank,

There

+2


source to share


6 answers


I would say that they are united. I think you will just create more work for yourself without getting a significant enough sum to justify it if you share that kind of information.



Authlogic is arguably the prettiest authentication plugin if you're looking for it. It recognizes some of the fields you are interested in (like last login, etc.) and is filled in automatically. The list is on their website.

+1


source


Keep everything in one model, easier at the beginning, avoids premature optimization, and you can always introduce a different model if really needed.



+1


source


I would agree, of course, to keep it in one model. If you have to expand / remove from the user model later, it will shorten your work. More importantly, if you design your User model well, you may not even need an additional "Profile" model, since most of the logic / description for the user is contained in the original user model. Then you can simply create an Accounts profile or controller that provides the user model fragments that you see fit. First decide if you want the absolute "Profile" item and from there. If not, you can still create it, but save the cost of having to create another model to support.

+1


source


A standalone model is also recommended here, along with using Authlogic. Fantastic library.

+1


source


So far I've always used restful_authentication, with some settings that were always fine, but I really need to have a game with Authlogic.

Regarding others' answers, I can see their points of view, simplicity is often very helpful, but I disagree that the correct answer is to put all this information in your user model. I would look at your application as a whole, how many models are you likely to have as a whole, how many, for example, would require an address? Directly from me, it would be very tempting to move the address into at least a separate model.

Personally, I think it's best to start with normalized tables and then perhaps evaluate de-normalization if you can justify the performance gain. Remember that you will likely load a user object frequently if you reach a high login speed that can be a source of improvement, which can be a source of improvement, which can be more difficult later down the line than it is now.

As with most things, this is a trade-off that must be answered in each set of circumstances. I hope that a different understanding is helpful, I just think you should consider the other side of the coin as well, hope that helps.

+1


source


Another vote for the same model. If you are thinking about performance, you are probably writing your own select query, etc., so in my eyes it doesn't matter how skinny or bold the model is in your case.

+1


source







All Articles