I''ve been striving to learn proper Rails practices and have an "opinionated" question. I''ve seen stated in many places that the business logic belongs primarily in the model. How important is that? I have a case in which I am tracking employee days off. My view will allow the user to enter the beginning and end date of their vacation, but I need to store the date of each day off separately. Further, I need to remove weekends and holidays. I have a good idea of how to do this in the controller by iterating through the dates and saving those that qualify. (I could populate a collection and do the save in one step, I suppose, but I''m not sure what the advantage would be.) So, is it okay, by Rails standards, to put this type of logic in the controller? Thanks. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
The code that iterates through the dates and creates the needed records is better in a model instead of a controller. The controller and view can gather the starting and ending dates, but then pass them to the model to do any business logic. Think about what would happen if you added a new type of interface to gather the date information - say a special version for mobile phone browsers. Or something that runs as part of a cron job that extracts the information from an external database. These can share the same model, and so your business logic is only in one place - the model. (This follows the DRY principle - Don''t Repeat Yourelf.) The business logic does not depend on how the dates are gathered, so it should not reside in a controller or view. Hope that helps. On Aug 28, 11:55 am, billv <billvan...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I''ve been striving to learn proper Rails practices and have an > "opinionated" question. I''ve seen stated in many places that the > business logic belongs primarily in the model. How important is that? > > I have a case in which I am tracking employee days off. My view will > allow the user to enter the beginning and end date of their vacation, > but I need to store the date of each day off separately. Further, I > need to remove weekends and holidays. > > I have a good idea of how to do this in the controller by iterating > through the dates and saving those that qualify. (I could populate a > collection and do the save in one step, I suppose, but I''m not sure > what the advantage would be.) > > So, is it okay, by Rails standards, to put this type of logic in the > controller? > > Thanks.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Yes, it does. Thank you. On Aug 28, 4:33 pm, hitch <larryhitc...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> The code that iterates through the dates and creates the needed > records is better in a model instead of a controller. > > The controller and view can gather the starting and ending dates, but > then pass them to the model to do any business logic. > > Think about what would happen if you added a new type of interface to > gather the date information - say a special version for mobile phone > browsers. Or something that runs as part of a cron job that extracts > the information from an external database. These can share the same > model, and so your business logic is only in one place - the model. > (This follows the DRY principle - Don''t Repeat Yourelf.) The business > logic does not depend on how the dates are gathered, so it should not > reside in a controller or view. > > Hope that helps. > > On Aug 28, 11:55 am, billv <billvan...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > I''ve been striving to learn proper Rails practices and have an > > "opinionated" question. I''ve seen stated in many places that the > > business logic belongs primarily in the model. How important is that? > > > I have a case in which I am tracking employee days off. My view will > > allow the user to enter the beginning and end date of their vacation, > > but I need to store the date of each day off separately. Further, I > > need to remove weekends and holidays. > > > I have a good idea of how to do this in the controller by iterating > > through the dates and saving those that qualify. (I could populate a > > collection and do the save in one step, I suppose, but I''m not sure > > what the advantage would be.) > > > So, is it okay, by Rails standards, to put this type of logic in the > > controller? > > > Thanks.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
billv wrote:> I''ve been striving to learn proper Rails practices and have an > "opinionated" question. I''ve seen stated in many places that the > business logic belongs primarily in the model. How important is that?Easy: Anything your user can do to your model, thru the View... ...a unit test can do to your Model, without the Controller''s help The controller should be considered just a dab of glue between View and Model.> I have a case in which I am tracking employee days off. My view will > allow the user to enter the beginning and end date of their vacation, > but I need to store the date of each day off separately. Further, I > need to remove weekends and holidays. > > I have a good idea of how to do this in the controller by iterating > through the dates and saving those that qualify. (I could populate a > collection and do the save in one step, I suppose, but I''m not sure > what the advantage would be.)Refactor that logic into the Model and leave it there. Tests should then show you can pass dates into the Model, and it processes them appropriately. -- Phlip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> > So, is it okay, by Rails standards, to put this type of logic in the > controller? >A bunch of code in your controller that is doing business logic is usually because: a) you''re lazy (like me), or b) you like to code first, then refactor (again, like me) Most of the time, that code can delegated to the model instead. If it *really* doesn''t feel right for your current model, that''s usually a hint that there''s another model hiding in the code that you haven''t realized yet. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---