what''s the best place for code that''s used in several controllers? i have a site with several namespaces. one for admin and one for client (and some more) adding a new client is a (relative) complex process involving entries in several tables and creating folders to upload files. for example a client can create his own account but the admin can do the same of course, so they share a lot of code. does this code belong to the model since it''s business logic? but then the client model would make entries in the address model (and a few more) application.rb would be another option, but it''s quite a lot of code (and the client controller is not the only one), so this would become a very large file then... or is it better to create a lib (or several libs)? make one lib per controller? or one lib per model? What''s the best practice to place this shared logic? -- 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 -~----------~----~----~----~------~----~------~--~---
> does this code belong to the model since it''s business logic?I think this statement pretty much sums it up. I am not sure why a client model writing out it''s own address (or anything like it) would be an issue. What you''re really saying is that you are willing to delegate to the client object how it chooses to persist its own address info. Whether that''s a composed object within the client record or an associated (has_one) address should not matter to the person using it -- only that client.address returns a valid address. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
If adding a new client is that complex, I''d consider moving the logic to a Factory. While complex creation logic almost certainly belongs in the Domain layer, it doesn''t have to be placed in the model class itself. In fact, placing it in the model class can pollute it with extra responsibilities. And, by their very nature as implementations of the ActiveRecord pattern [ http://martinfowler.com/eaaCatalog/activeRecord.html ], models in Rails already have two responsibilities, domain behavior and persistence. The DDD Quickly book from InfoQ [ http://infoq.com/books/domain-driven-design-quickly ] is a good introduction to Domain Driven Design, which is the basis of my recommendation. Regards, Craig --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi Craig, I''m fairly new to the Rails framework. I''ve been using DDD techniques in other environments. I noticed that you mentioned Rails models have more than one responsibility. With regards to persistence, has any application and/or book touched on removing persistence away from the domain? I know ActiveRecord seems to be a major part of the framework and I like the ActiveRecord pattern for some things, but I''m curious about other options. Thanks, Shane On May 6, 11:11 am, "Craig Demyanovich" <cdemyanov...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> If adding a new client is that complex, I''d consider moving the logic to a > Factory. While complex creation logic almost certainly belongs in the Domain > layer, it doesn''t have to be placed in the model class itself. In fact, > placing it in the model class can pollute it with extra responsibilities. > And, by their very nature as implementations of the ActiveRecord pattern [http://martinfowler.com/eaaCatalog/activeRecord.html], models in Rails > already have two responsibilities, domain behavior and persistence. > > The DDD Quickly book from InfoQ [http://infoq.com/books/domain-driven-design-quickly] is a good introduction > to Domain Driven Design, which is the basis of my recommendation. > > Regards, > Craig--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Shane, I only know that many people strive to limit their ActiveRecord models to domain + persistence by moving logic to other objects. I think many people mistakenly stick to just using models, views and controllers when they come to Rails, instead of creating, for example, other plain Ruby classes and modules to break up responsibilities. I don''t know if there are other persistence options for Rails. Merb [ http://merbivore.com/ ], however, supports Sequel and DataMapper in addition to ActiveRecord. I haven''t yet used Merb, Sequel or DataMapper, but they''re on my to-do list. Give them a look. Craig On Tue, May 6, 2008 at 11:26 AM, Shane Bauer <shane-JlpJe8x41SO+XT7JhA+gdA@public.gmane.org> wrote:> > Hi Craig, > > I''m fairly new to the Rails framework. I''ve been using DDD techniques > in other environments. I noticed that you mentioned Rails models have > more than one responsibility. With regards to persistence, has any > application and/or book touched on removing persistence away from the > domain? I know ActiveRecord seems to be a major part of the framework > and I like the ActiveRecord pattern for some things, but I''m curious > about other options. > > Thanks, > Shane > > On May 6, 11:11 am, "Craig Demyanovich" <cdemyanov...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > wrote: > > If adding a new client is that complex, I''d consider moving the logic to > a > > Factory. While complex creation logic almost certainly belongs in the > Domain > > layer, it doesn''t have to be placed in the model class itself. In fact, > > placing it in the model class can pollute it with extra > responsibilities. > > And, by their very nature as implementations of the ActiveRecord pattern > [http://martinfowler.com/eaaCatalog/activeRecord.html], models in Rails > > already have two responsibilities, domain behavior and persistence. > > > > The DDD Quickly book from InfoQ [ > http://infoq.com/books/domain-driven-design-quickly] is a good > introduction > > to Domain Driven Design, which is the basis of my recommendation. > > > > Regards, > > Craig > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Another option that may be familiar from other environments is rbatis, the Ruby port of the iBatis ORM by ThoughtWorks. I''ve used it with some success in the past. My one complaint about the solution was that it required you to create the maps in the class rather than in some external (xml/yml/etc) file. However, I''ve recently been playing with the AppConfig plugin to try to get around some of those issues. Anyway, it''s another option in the sphere that DataMapper fills. On May 6, 3:48 pm, "Craig Demyanovich" <cdemyanov...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Shane, > > I only know that many people strive to limit their ActiveRecord models to > domain + persistence by moving logic to other objects. I think many people > mistakenly stick to just using models, views and controllers when they come > to Rails, instead of creating, for example, other plain Ruby classes and > modules to break up responsibilities. > > I don''t know if there are other persistence options for Rails. Merb [http://merbivore.com/], however, supports Sequel and DataMapper in addition > to ActiveRecord. I haven''t yet used Merb, Sequel or DataMapper, but they''re > on my to-do list. Give them a look. > > Craig > > On Tue, May 6, 2008 at 11:26 AM, Shane Bauer <sh...-JlpJe8x41SO+XT7JhA+gdA@public.gmane.org> wrote: > > > Hi Craig, > > > I''m fairly new to the Rails framework. I''ve been using DDD techniques > > in other environments. I noticed that you mentioned Rails models have > > more than one responsibility. With regards to persistence, has any > > application and/or book touched on removing persistence away from the > > domain? I know ActiveRecord seems to be a major part of the framework > > and I like the ActiveRecord pattern for some things, but I''m curious > > about other options. > > > Thanks, > > Shane > > > On May 6, 11:11 am, "Craig Demyanovich" <cdemyanov...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > wrote: > > > If adding a new client is that complex, I''d consider moving the logic to > > a > > > Factory. While complex creation logic almost certainly belongs in the > > Domain > > > layer, it doesn''t have to be placed in the model class itself. In fact, > > > placing it in the model class can pollute it with extra > > responsibilities. > > > And, by their very nature as implementations of the ActiveRecord pattern > > [http://martinfowler.com/eaaCatalog/activeRecord.html], models in Rails > > > already have two responsibilities, domain behavior and persistence. > > > > The DDD Quickly book from InfoQ [ > >http://infoq.com/books/domain-driven-design-quickly] is a good > > introduction > > > to Domain Driven Design, which is the basis of my recommendation. > > > > Regards, > > > Craig--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Thanks Craig and Andy. I installed the gem for Merb, but haven''t done anything with it yet, though. I''ll take a look at it today as well as the others. A lot of good stuff to take a look at today. I appreciate it. Shane On May 6, 3:48 pm, "Craig Demyanovich" <cdemyanov...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Shane, > > I only know that many people strive to limit their ActiveRecord models to > domain + persistence by moving logic to other objects. I think many people > mistakenly stick to just using models, views and controllers when they come > to Rails, instead of creating, for example, other plain Ruby classes and > modules to break up responsibilities. > > I don''t know if there are other persistence options for Rails. Merb [http://merbivore.com/], however, supports Sequel and DataMapper in addition > to ActiveRecord. I haven''t yet used Merb, Sequel or DataMapper, but they''re > on my to-do list. Give them a look. > > Craig > > On Tue, May 6, 2008 at 11:26 AM, Shane Bauer <sh...-JlpJe8x41SO+XT7JhA+gdA@public.gmane.org> wrote: > > > Hi Craig, > > > I''m fairly new to the Rails framework. I''ve been using DDD techniques > > in other environments. I noticed that you mentioned Rails models have > > more than one responsibility. With regards to persistence, has any > > application and/or book touched on removing persistence away from the > > domain? I know ActiveRecord seems to be a major part of the framework > > and I like the ActiveRecord pattern for some things, but I''m curious > > about other options. > > > Thanks, > > Shane > > > On May 6, 11:11 am, "Craig Demyanovich" <cdemyanov...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > wrote: > > > If adding a new client is that complex, I''d consider moving the logic to > > a > > > Factory. While complex creation logic almost certainly belongs in the > > Domain > > > layer, it doesn''t have to be placed in the model class itself. In fact, > > > placing it in the model class can pollute it with extra > > responsibilities. > > > And, by their very nature as implementations of the ActiveRecord pattern > > [http://martinfowler.com/eaaCatalog/activeRecord.html], models in Rails > > > already have two responsibilities, domain behavior and persistence. > > > > The DDD Quickly book from InfoQ [ > >http://infoq.com/books/domain-driven-design-quickly] is a good > > introduction > > > to Domain Driven Design, which is the basis of my recommendation. > > > > Regards, > > > Craig--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---