Hi Ryan,
It seems this code is brittle. At the moment we have a method and an instance variable for accessing to current user data. Data associated with him/her can be corrupted in any other object methods. By the way, what if I assign some value to @current_user before calling current_user method? Right, @current_user would never be filled with data from Data Base.
I agree, caching could be very useful, but we should be as accurate as we can. Caching solution is a synchronization trouble, I guess. So what about to incapsulate data caching in data class?
ruby
classUser < ActiveRecord::Basedefself.find_by_id(id)
# we can hold @last_requested_user variable and compare# given id with @last_requested_user.id and then return# right user... or something like this.endend
Merely User class knows when its data was changed, so caching of some part of data is responsability of User class. One more argument for this solution is that, actually, User class is only point access to data, so we have to incapsulte logic like this in data classes, dont'we?
Hi Ryan,
It seems this code is brittle. At the moment we have a method and an instance variable for accessing to current user data. Data associated with him/her can be corrupted in any other object methods. By the way, what if I assign some value to
@current_user
before callingcurrent_user
method? Right,@current_user
would never be filled with data from Data Base.I agree, caching could be very useful, but we should be as accurate as we can. Caching solution is a synchronization trouble, I guess. So what about to incapsulate data caching in data class?
Merely User class knows when its data was changed, so caching of some part of data is responsability of User class. One more argument for this solution is that, actually, User class is only point access to data, so we have to incapsulte logic like this in data classes, dont'we?