Is it reasonable, for the model objects to never call save inside any given method, and leave that responsibility to the controller? If so, what are the exceptions? If not, what guidelines are recommended here for when to call save? David
I never call save inside my model, as I want to try and keep the code handling persistence completely seperate from my model (well, as seperate as possible given that ActiveRecord gives me persistence support in the model itself!). The model should be a (IMHO) pure domain object - the code should be as much as possible about the domain object logic and it''s interactions with other domain objects. All of my saving/loading/finding is done in the controllers or their delegates - I''m even tempted to create a seperate repository layer used by the controllers to allow be to better test controllers (e.g. mock out the repository layer, post to a controller, check the relevent save/load/find methods get called on the mock repository). sam On 5/22/05, David Corbin <dcorbin-wmGZ+vDKSyrZJqsBc5GL+g@public.gmane.org> wrote:> Is it reasonable, for the model objects to never call save inside any given > method, and leave that responsibility to the controller? > > If so, what are the exceptions? > > If not, what guidelines are recommended here for when to call save? > > David > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- sam http://www.magpiebrain.com/
On Monday 23 May 2005 04:25 am, Sam Newman wrote:> I never call save inside my model, as I want to try and keep the code > handling persistence completely seperate from my model (well, as > seperate as possible given that ActiveRecord gives me persistence > support in the model itself!). The model should be a (IMHO) pure > domain object - the code should be as much as possible about the > domain object logic and it''s interactions with other domain objects. > > All of my saving/loading/finding is done in the controllers or their > delegates - I''m even tempted to create a seperate repository layer > used by the controllers to allow be to better test controllers (e.g. > mock out the repository layer, post to a controller, check the > relevent save/load/find methods get called on the mock repository). >I like that idea. Share it with us if the temptation bares fruit....
It''s not really my idea - I got it from Eric Evan''s Domain Driven Design book (highly recommended), and he certainly didn''t invent it. As soon as I get my head round Ruby''s mocking libraries (I''m so used to JMock) I''ll give the repository layer a go and stick a write-up on the wiki or something. Amongst other things, one of the advantages of the seperate layer is that as a Rails application mature, it can develop more and more functionality which might (due to performance or modelling requirements) require the (partial) seperation of the model from the persistence mechanism. By hiding persistence behind a repository layer you make it easy to change persistence mapping in those specific areas. The fact that ActiveRecord already gives you all the persistence stuff you need initially makes the initial creation of the repository layer laughably simple. Now all I have to do is work out how to create a controller with a Repository in order to mock one for testing... sam On 5/24/05, David Corbin <dcorbin-wmGZ+vDKSyrZJqsBc5GL+g@public.gmane.org> wrote:> On Monday 23 May 2005 04:25 am, Sam Newman wrote: > > I never call save inside my model, as I want to try and keep the code > > handling persistence completely seperate from my model (well, as > > seperate as possible given that ActiveRecord gives me persistence > > support in the model itself!). The model should be a (IMHO) pure > > domain object - the code should be as much as possible about the > > domain object logic and it''s interactions with other domain objects. > > > > All of my saving/loading/finding is done in the controllers or their > > delegates - I''m even tempted to create a seperate repository layer > > used by the controllers to allow be to better test controllers (e.g. > > mock out the repository layer, post to a controller, check the > > relevent save/load/find methods get called on the mock repository). > > > > I like that idea. Share it with us if the temptation bares fruit.... >-- sam http://www.magpiebrain.com/
On Tuesday 24 May 2005 04:14 am, Sam Newman wrote:> It''s not really my idea - I got it from Eric Evan''s Domain Driven > Design book (highly recommended), and he certainly didn''t invent it.Your comment simply sparked an idea for me. It hadn''t occurred to me to introduce a persistence abstraction between the controller and the model. I''ve been thinking in terms of trying to introduce one under the model. Doing one in between should be very simple, I would think.> As soon as I get my head round Ruby''s mocking libraries (I''m so used > to JMock) I''ll give the repository layer a go and stick a write-up on > the wiki or something.I''ve never used the mocks libraries in Ruby, but in Java I''ve decided they''re not worth the effort. Better to hand-write a mock that is simple and clear and makes my test very readable. Might be the same in Ruby. Might not. David