So you keep your Rails models as simply a data-access later, and move all domain logic to a mirrored set of classes that are easy to unit test in isolation?
On 26 August 2011 16:15, Scott Harvey <[email protected]> wrote: > > However, due to Rail's tight coupling of the models and the database > layer I > > will concede that there are times when you have no choice but to hit the > > database (e.g. for testing CRUD operatios and testing the result of a > named > > scope that relies on an aggregation performed in a database query - you > need > > to test that named scope, and if the work is happing in the DB then > you'll > > need it for the unit test) > > I guess this might be an argument for restructuring your Rails > application so your models stick to the Single Responsibility > Principle. > > An approach to this was outlined by Yehuda in this Stack Overflow answer. > > > http://stackoverflow.com/questions/1068558/oo-design-in-rails-where-to-put-stuff/1071510#1071510 > > I haven't tried this myself or seen any other applications using this > pattern but it sounds good in principle and would decouple a lot of > classes from the database layer. > > Scott > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > -- James -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
