I am working on re-factoring my admittedly ambitious employee
management Rails app that I created for work. The good news is, my
first major version went over like a dream(With no small amount of
thanks due to the community and the support)! All of the functionality
the bosses dreamed of! The bad news? It’s REALLY SLOW. So I rolled up
my sleeves and have been working on some re-writes that are showing a
tremendous amount of progress(This is my first major app!)
My initial page crunches and loads data from 5 separate tables. There
is a lot of logic that goes into supporting the Model the entire app
is designed around (appropriately named the DaySchedule object).
Within the views there are a lot of calls made from database
DaySchedule.assignment.assignment_name, you get the idea). These
related models are vital for the views, but I know that they are
killing my render time . . . I also know that db access in the views
is a big no no.
I was wondering what others did when faced with this? My thought has
been to initialize a bunch of “virtual attributes” when instantiating
the DaySchedule object back in the model. (going from
DaySchedule.employee.full_name to a DaySchedule.full_name method that
I set up with initialize so it is in memory). Does this sound like the
right thing to do? What are best practices when an object has a large
amount of associations with other models and the view needs access to
those related objects?