Rails antipatterns

What Hacker News says

1. sonnymFeb 2015
   Aside from the things others have mentioned, which are all really good, there are some really good books on the subject.

   Jose Valim's Crafting Rails Applications[1] is a wonderful resource, since it deliberately sets out to peel back the layers of magic. A lot of the techniques are ones I probably would not use in practice (storing views in the database and rendering them!), but they serve to elucidate the operation of the entire view stack. Really good stuff.

   Two other good books are Rails Antipatterns[2] and Objects on Rails[3]. Neither of them has been updated in a long time, but the general principles will still hold. The former is more practical, the latter more theoretical; precscriptive and fanciful food for thought, respectively. Both solid.

   1. https://pragprog.com/book/jvrails2/crafting-rails-4-applicat...

   2. http://railsantipatterns.com/

   3. http://objectsonrails.com/

   Show morethread
2. dkannanOct 2012
   check http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison...

   other than that, 1. write tests 2. good community. for some measure of good

   thread
3. alttabJul 2012
   This is certainly interesting. I like the event based model. Here are my thoughts:

   If your controllers are getting fat and spaghetti like, I wouldn't blame MVC. There are many patterns one can use that are compatible with MVC without going to a completely different architecture. For instance, if you need to encapsulate multi-model interaction you can create a presenter abstraction that the controller simply calls into. Just because there is a bunch of code that ends up in the controller because "you don't know where to put it" doesn't mean there isn't a better place to put it without re-designing the entire application.

   Another thing is while I love the data-binding event deal, this really only works for client-side frameworks like Backbone. Server-side kinda goes at the window, but I suppose you could add a framework that piped event signals in the response from changes that occurred in the ORM layer (although this further couples components).

   I'm not convinced that separating the data from the methods that operate is a great idea unless you want to go purely functional. Doing this clearly breaks encapsulation, throws any notion of OOP out the window, and still binds the "operations" too closely to the data. Generally speaking, the data is useless without the operations and vice versa.

   So the real difference between MOVE and MVC, at least according to this article, is that models are no longer useful on their own, the controllers aka "operations" know everything about how to manipulate models (it shouldn't), and models generate events which are only consumed by views, which makes no sense if you wanted to use the model on its own (but you can't without your operations).

   Generally speaking, the model should MODEL something. That includes data and behavior. Without both, you have a database, and a set of operations kinda like a C library but only because OOP hadn't been invented yet.

   In my mind this further couples all of the components because it actually increases the reliance on each other for them to be useful.

   MVC isn't dead. There is a good chance you are using it wrong. I highly suggest Rails Antipatterns. While it is specific to Rails, it works for MVC in general. http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison...

   edit: spelling

   Show morethread
4. alttabOct 2011
   Read this: http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison...

   Easiest mistake in large rails apps is to let your controllers get too thick...

   thread
5. cicatrizAug 2011
   The book Rails AntiPatterns addresses many: http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison...
   thread
6. jcapoteMay 2011
   http://www.amazon.com/Rails-AntiPatterns-Refactoring-Addison...

   http://www.amazon.com/Crafting-Rails-Applications-Developmen...

   thread