# Shared controller logic **URL:** \ **Category:** Rails\ **Created:** [May 6, 2008, 11:08am UTC](https://www.ruby-forum.com/t/shared-controller-logic/136775 "2008-05-06T11:08:44Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![thorsten](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d2c977/32.png) [@thorsten](https://www.ruby-forum.com/u/thorsten)\ **Post date:** [May 6, 2008, 11:08am UTC](https://www.ruby-forum.com/t/shared-controller-logic/136775/1 "2008-05-06T11:08:44Z")
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? ---
**Author:** ![thorsten](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d2c977/32.png) [@thorsten](https://www.ruby-forum.com/u/thorsten)\ **Post date:** [May 6, 2008, 3:46pm UTC](https://www.ruby-forum.com/t/shared-controller-logic/136775/2 "2008-05-06T15:46:36Z")
> 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. ---
**Author:** ![thorsten](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d2c977/32.png) [@thorsten](https://www.ruby-forum.com/u/thorsten)\ **Post date:** [May 6, 2008, 5:12pm UTC](https://www.ruby-forum.com/t/shared-controller-logic/136775/3 "2008-05-06T17:12:19Z")
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 [ [P of EAA: Active Record](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](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 ---
**Author:** ![thorsten](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d2c977/32.png) [@thorsten](https://www.ruby-forum.com/u/thorsten)\ **Post date:** [May 6, 2008, 6:46pm UTC](https://www.ruby-forum.com/t/shared-controller-logic/136775/4 "2008-05-06T18:46:11Z")
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 D.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![thorsten](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d2c977/32.png) [@thorsten](https://www.ruby-forum.com/u/thorsten)\ **Post date:** [May 6, 2008, 9:49pm UTC](https://www.ruby-forum.com/t/shared-controller-logic/136775/5 "2008-05-06T21:49:34Z")
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/](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 ---
**Author:** ![thorsten](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d2c977/32.png) [@thorsten](https://www.ruby-forum.com/u/thorsten)\ **Post date:** [May 7, 2008, 4:36pm UTC](https://www.ruby-forum.com/t/shared-controller-logic/136775/6 "2008-05-07T16:36:35Z")
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 ---
**Author:** ![thorsten](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/d2c977/32.png) [@thorsten](https://www.ruby-forum.com/u/thorsten)\ **Post date:** [May 7, 2008, 2:42pm UTC](https://www.ruby-forum.com/t/shared-controller-logic/136775/7 "2008-05-07T14:42:47Z")
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.