# ActiveRecord and Form Data Coupling: A Bad Design **URL:** \ **Category:** Rails\ **Created:** [October 14, 2007, 7:16am UTC](https://www.ruby-forum.com/t/activerecord-and-form-data-coupling-a-bad-design/117170 "2007-10-14T07:16:05Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![ProfKheel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ba0ec/32.png) [@ProfKheel](https://www.ruby-forum.com/u/ProfKheel)\ **Post date:** [October 14, 2007, 7:16am UTC](https://www.ruby-forum.com/t/activerecord-and-form-data-coupling-a-bad-design/117170/1 "2007-10-14T07:16:05Z")
I have to say that after being a Rails user for some time I have grown to really dislike how ActiveRecord (AR) classes - models - are being pushed as the defacto method for getting form data into the DB. The two concepts are completely separate and should be handled by completely different classes. Anyone who understands Object Oriented Design knows that we separate classes based on functionality and responsibility. An automobile class, for example, would represent something that has wheels and drives; a fixed-wing aircraft class would represent something that flies. Such is the case with AR, it handles the interaction with the database and holds the data, and perhaps has some extra methods that interact with the data it holds. Also, what we see a lot of is having the AR class also handle data coming from a form, which breaks encapsulation. It’s like saying that to build the ultimate vehicle would be to put wings on a car because it would be get us in a jiffy whether we had to go short or long distances (a nice idea, but try driving down Broadway with wings spanning forty feet). The problem with coupling the form and the AR is that it may have very little resemblance to the form that is creating it. I’ve encountered this quite a bit. For registration (user model) I had to add a number of attributes to the class that had no mapping to the db, that hung around and cluttered up the design tremendously. Furthermore, the need to have those attributes validated compounded the problem further since some could only be validated on create or on update. Also whenever I wanted to save the object when not in form mode i always needed extra code to flag or message the object so that it wouldn’t validate itself - a time consuming and unnecessary task. The ultimate solution was to do what OOD says to do - break out the forms into a completely separate class that handled and validated the form data and then passed the data to the AR object. Needless to say, it took quite a bit of time to do, and I think it’s the best solution. I hope that the next versions of Rails will contain some kind of ActiveForm class for the sake of others. ---
**Author:** ![ProfKheel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ba0ec/32.png) [@ProfKheel](https://www.ruby-forum.com/u/ProfKheel)\ **Post date:** [October 14, 2007, 7:41am UTC](https://www.ruby-forum.com/t/activerecord-and-form-data-coupling-a-bad-design/117170/2 "2007-10-14T07:41:13Z")
On 10/14/07, ProfKheel [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > drives; a fixed-wing aircraft class would represent something that > little resemblance to the form that is creating it. I’ve encountered > forms into a completely separate class that handled and validated the > form data and then passed the data to the AR object. Needless to say, > it took quite a bit of time to do, and I think it’s the best > solution. I hope that the next versions of Rails will contain some > kind of ActiveForm class for the sake of others. I’m sure we’ve all run into this at one point or another for non-trivial forms. But, this kind of radical change is best served as a plugin to start. Share your active\_form plugin with the world and prove with real code in production that it kicks ass. One thing I would like to do, for start, is extract some of the common ‘model’ code out of ActiveRecord into some kind of ActiveModel class. This includes basic validation functionality, as well as callbacks possibly. It’s something I may look into later after Rails 2.0 has been released. – Rick O. [http://lighthouseapp.com](http://lighthouseapp.com) [http://weblog.techno-weenie.net](http://weblog.techno-weenie.net) [http://mephistoblog.com](http://mephistoblog.com) ---
**Author:** ![ProfKheel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ba0ec/32.png) [@ProfKheel](https://www.ruby-forum.com/u/ProfKheel)\ **Post date:** [October 14, 2007, 9:24am UTC](https://www.ruby-forum.com/t/activerecord-and-form-data-coupling-a-bad-design/117170/3 "2007-10-14T09:24:39Z")
On 10/13/07, ProfKheel [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > drives; a fixed-wing aircraft class would represent something that > little resemblance to the form that is creating it. I’ve encountered > forms into a completely separate class that handled and validated the > form data and then passed the data to the AR object. Needless to say, > it took quite a bit of time to do, and I think it’s the best > solution. I hope that the next versions of Rails will contain some > kind of ActiveForm class for the sake of others. > > > You might find the Presenter pattern useful: > **[Rails: Presenter Pattern](http://blog.jayfields.com/2007/03/rails-presenter-pattern.html)** > > The default architecture for Ruby on Rails, Model View Controller, can begin to break down as Controllers become bloated and logic begins to... Pat ---
**Author:** ![ProfKheel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/7ba0ec/32.png) [@ProfKheel](https://www.ruby-forum.com/u/ProfKheel)\ **Post date:** [October 14, 2007, 10:18am UTC](https://www.ruby-forum.com/t/activerecord-and-form-data-coupling-a-bad-design/117170/4 "2007-10-14T10:18:26Z")
On Oct 13, 2007, at 10:40 PM, Rick O. wrote: > > classes based on functionality and responsibility. An automobile > > driving down Broadway with wings spanning forty feet). > > since some could only be validated on create or on update. Also > > kind of ActiveForm class for the sake of others. > > been released. > > The current design seems “natural” to me because 9x of 10 it’s what > > you want. Form data goes into table either verbatim or with few > > manipulations. But for that 1x, it’s a pain. I’ve used my own framework for several years now which had validation coupled to the form-to-table process as well. I also started to get more annoyed when I needed things just a hair outside the norm. Quite recently, I finally decoupled the validation process and forma data storage as you’re suggesting so I could accept and validate forms w/o being forced to map that onto a table at that instant. However, I did it in a way that the ORM and validation system did have intimate enough knowledge to still provide that automatic magic with virtually no effort. While that may also be imperfect OOD, it seemed the right thing to do to preserve the magic, yet not be hostage to it as well. Vague, I know, but just saying that I think a design compromise is both possible and worthwhile. – gw