Jump to content

The ultimate community for Ruby on Rails developers.


Photo

Fat Vs. Skinny


  • Please log in to reply
19 replies to this topic

Poll: Controllers & Models (21 member(s) have cast votes)

What's your current style? Fat Controllers + Skinny Models

  1. Fat Controllers & Skinny Models (6 votes [28.57%] - View)

    Percentage of vote: 28.57%

  2. Skinny Controllers & Fat Models (15 votes [71.43%] - View)

    Percentage of vote: 71.43%

Are you happy with your style?

  1. Yes (13 votes [61.90%] - View)

    Percentage of vote: 61.90%

  2. No (6 votes [28.57%] - View)

    Percentage of vote: 28.57%

  3. Not bothered (2 votes [9.52%] - View)

    Percentage of vote: 9.52%

Vote Guests cannot vote

#1 Jamie

Jamie

    Controller

  • Moderators
  • 114 posts
  • LocationThe UK

Posted 17 August 2013 - 04:12 PM

I wanted to start a discussion around Controllers, Models & Views and our coding styles.

 

I often pump a lot of fat into my controllers while keeping my models pretty basic.

 

I would imagine a well-seasoned Rails developer would laugh at my controllers as it contains a lot scope logic, which is often found in another controllers/modules.

 

But hey... This is a learning game and I'm far from a good Rails programmer - I'm only 6/8 months into it - I want to known how you guys tend to code and do you have any tips to remind yourself on where code should be placed or do you just wait until it's time to refactor?

 

I find myself wasting time refactoring on the go quite often which could delay a project if I didn't pull all-nighters too. Again... This is just how I do things.. I would to try out other methods that people share.

 

 

So... The real question is... What's your style?


Rails developer based in Newcastle, UK.
Web app owner - Twitter lover

#2 james

james

    Guard

  • Moderators
  • 221 posts
  • LocationLeeds, U.K.

Posted 17 August 2013 - 04:51 PM

I often pump a lot of fat into my controllers while keeping my models pretty basic.

 

 

I think you need a mind shift towards OO design and approaches. OO is a state of mind! It's about understanding how Rails gives you all the place holders to help you take an OO approach and it's about what Rails developers term DRY (Don't Repeat Yourself) because OO isn;t applicable to HTML

 

Might I suggest that you get into a PURE OO language. Do some pure Ruby stuff or some Smalltalk stuff and ditch RoR for a few months. Come back to RoR when you have an OO mindset and you shouldl have a better understanding of exactly what Rails can do for you.


  • AstonJ likes this

Programming is just about problem solving!


#3 Tom

Tom

    Signalman

  • Members
  • 25 posts

Posted 17 August 2013 - 05:17 PM

When I'm writing something from scratch (without much planning) that's exactly what I do. I think it's very natural to get things going in a controller and then refactor them to the model. It takes a lot of foresight to build a fat model from the start. Regardless of how you do it, skinny controllers and fat models is where you want to end up.
  • james likes this

#4 james

james

    Guard

  • Moderators
  • 221 posts
  • LocationLeeds, U.K.

Posted 17 August 2013 - 05:26 PM

It takes a lot of foresight to build a fat model from the start.

 

 

You are so right! That forsight comes from TBDD (Test Behavioural Driven Development). It really focuses the mind and prevents a lot of back tracking and wasted code plus it gives you a comfortable feeling knowing that all your methods are working the way you want them. TBDD is essential to produce a quality app in any interpreted language as you don't have a compiler to pick up on your typos.


  • Tom likes this

Programming is just about problem solving!


#5 AstonJ

AstonJ

    Dispatcher

  • Members
  • 35 posts

Posted 17 August 2013 - 10:16 PM

I try to follow idiomatic Ruby and Rails wherever possible - there are some really smart guys in these communities and I've found it best to follow their lead :D

 

So yeah, I voted fat models :P


  • james likes this

:)


#6 Andre Dublin

Andre Dublin

    Signalman

  • Members
  • 13 posts
  • LocationCharleston, SC

Posted 17 August 2013 - 10:45 PM

Wheres the skinny models & skinny controllers option!?



#7 Tom

Tom

    Signalman

  • Members
  • 25 posts

Posted 17 August 2013 - 10:50 PM

Wheres the skinny models & skinny controllers option!?

rails new superskinny

It's right after you run that command. Or here. :D



#8 Andre Dublin

Andre Dublin

    Signalman

  • Members
  • 13 posts
  • LocationCharleston, SC

Posted 18 August 2013 - 03:43 PM

rails new superskinny

It's right after you run that command. Or here. :D

 

 

I see what you did there.



#9 Jemagee

Jemagee

    Inspector

  • Members
  • 62 posts

Posted 19 August 2013 - 02:45 PM

As someone who comes from the 'database' world into OOP and Rails, I somehow feel I'll end up with fatter models than most.  In fact my hold up right now in even beginning to build my blog engine is that I want to get the database design refined, which may be the wrong way to do things



#10 katafrakt

katafrakt

    Signalman

  • Members
  • 16 posts
  • LocationKraków, PL

Posted 19 August 2013 - 03:04 PM

Wheres the skinny models & skinny controllers option!?

In the mythical land flowing with milk and honey where every Rails programmer longs to be.

And this is actually achievable using concerns and services. But requires an awful lot of self-discipline.


  • Jamie likes this

#11 noz

noz

    Signalman

  • Members
  • 21 posts

Posted 19 August 2013 - 05:01 PM

In the mythical land flowing with milk and honey where every Rails programmer longs to be.

And this is actually achievable using concerns and services. But requires an awful lot of self-discipline.

Personally, I'm not a huge fan of concerns and service objects, it all seems really gimmicky to me. I haven't come across a scenario just yet where it really made sense to introduce that extra layer of complexity to my architecture, but maybe I'm just not using it right.



#12 james

james

    Guard

  • Moderators
  • 221 posts
  • LocationLeeds, U.K.

Posted 19 August 2013 - 05:36 PM

I have worked on large (I mean huge) projects involving thousands to tables in other languages and I have had to trawl through COBOL files regularly containing 1,000+ lines of code to find one tiny bug and it was like untangling strings of spaghetti but it was still more comfortable than dealing with a large model.

 

Again in Delphi on major projects I have worked on I often had classes with 2 or 3 hundred lines of code and it wasn't a problem at all.

 

On a Rails project last year I ended up with a very fat model with over 100 lines of code. which, in the scheme of things, was tiny. but really really awkward to work with.

 

Fat models are the way to go but for some reason I find unexplainable they seem difficult to manage compared to other languages but I just can't put my finger on why. It is something to do with navigating around the file and I think that this is the reason why skinny models are becoming popular because others are feeling the same.


Programming is just about problem solving!


#13 noz

noz

    Signalman

  • Members
  • 21 posts

Posted 19 August 2013 - 06:24 PM

I have worked on large (I mean huge) projects involving thousands to tables in other languages and I have had to trawl through COBOL files regularly containing 1,000+ lines of code to find one tiny bug and it was like untangling strings of spaghetti but it was still more comfortable than dealing with a large model.

 

Again in Delphi on major projects I have worked on I often had classes with 2 or 3 hundred lines of code and it wasn't a problem at all.

 

On a Rails project last year I ended up with a very fat model with over 100 lines of code. which, in the scheme of things, was tiny. but really really awkward to work with.

 

Fat models are the way to go but for some reason I find unexplainable they seem difficult to manage compared to other languages but I just can't put my finger on why. It is something to do with navigating around the file and I think that this is the reason why skinny models are becoming popular because others are feeling the same.

100 lines is considered fat? My models must be obese then.  :unsure:


  • michalgritzbach likes this

#14 Kelli Shaver

Kelli Shaver

    Inspector

  • Administrators
  • 75 posts
  • LocationKentucky

Posted 19 August 2013 - 06:39 PM

I tend to have a lot of logic in my controllers on the first pass through an app, especially if I'm in a hurry to get something up out there. Then I go back and move things into the model when it makes sense to. For some reason, the initial "get stuff up and working" sprint feels easier/faster if I do it that way, but I prefer to move as much logic into the model as makes sense to. 



#15 katafrakt

katafrakt

    Signalman

  • Members
  • 16 posts
  • LocationKraków, PL

Posted 20 August 2013 - 07:53 AM

Personally, I'm not a huge fan of concerns and service objects, it all seems really gimmicky to me. I haven't come across a scenario just yet where it really made sense to introduce that extra layer of complexity to my architecture, but maybe I'm just not using it right.

I generally agree that it is not so good for small and/or managed by one or two people projects. But where I currently work, we are dealing with really huge rails apps, models can sometimes have near thousand lines and it is really helpful to move some of it to concerns. First - for clarity. Second - for testing.



#16 Ohm

Ohm

    Guard

  • Members
  • 186 posts
  • LocationCopenhagen

Posted 20 August 2013 - 08:27 AM

I generally agree that it is not so good for small and/or managed by one or two people projects. But where I currently work, we are dealing with really huge rails apps, models can sometimes have near thousand lines and it is really helpful to move some of it to concerns. First - for clarity. Second - for testing.

 

I haven't used concerns myself yet and I am having a hard time grasping the concept.

 

Lets say I have a fat model, that I want to thin down. Should I just put some of its code into a concern, whether or not other models will use the same concern?

 

As I read it, concerns are suppose to be shared logic between models, but I might be wrong, and you might just move some of the model into concerns.

 

Is concerns just a grouping of logic?


Blog: http://ohm.sh | Twitter: madsohm


#17 Kelli Shaver

Kelli Shaver

    Inspector

  • Administrators
  • 75 posts
  • LocationKentucky

Posted 20 August 2013 - 04:57 PM

I need to look into using concerns (which, I agree, sound like they could be overkill for small projects, but useful for big ones). I haven't really had time to do anything with them yet. 

 

 

 

As I read it, concerns are suppose to be shared logic between models, but I might be wrong, and you might just move some of the model into concerns.

 

Is concerns just a grouping of logic?

 

It may not be the most Rails-y way, but IMO, both use cases would be perfectly acceptable, so long as you were consistent. 



#18 Ohm

Ohm

    Guard

  • Members
  • 186 posts
  • LocationCopenhagen

Posted 20 August 2013 - 06:26 PM

It may not be the most Rails-y way, but IMO, both use cases would be perfectly acceptable, so long as you were consistent. 

 

Oh, don't get me wrong. Both sound awesome, I just can't imagine a scenario where I would group my shared logic in a concern, rather than having the two models sharing in both inherit from the same super model. However the grouping of logic sounds very appealing for large projects. I'll have to look into that and suggest it at work.


Blog: http://ohm.sh | Twitter: madsohm


#19 alejandro

alejandro

    Passenger

  • Members
  • 2 posts

Posted 21 August 2013 - 01:56 PM

There are good ideas in this post.



#20 katafrakt

katafrakt

    Signalman

  • Members
  • 16 posts
  • LocationKraków, PL

Posted 21 August 2013 - 09:06 PM

Lets say I have a fat model, that I want to thin down. Should I just put some of its code into a concern, whether or not other models will use the same concern?

 

As I read it, concerns are suppose to be shared logic between models, but I might be wrong, and you might just move some of the model into concerns.

Of course, shared login is an ideal scenario for concerns. But if you have a fat model I personally don't see anything wrong with putting some of the logic (as long as it is some complete thing, not just random methods put in there) away from model itself. It is a way of havin Single Responsibility Principle in Rails, which is not always achievable in other ways.

 

To give some example, I could think of MediaWiki clone in Rails. When you save a page you trigger all the after-save logic of gathering the links between pages and updating linking records. Scanning for links and updating the links table is a separate part of the logic that can be safely moved outside the Page model and exist as a concern, even if no other model uses this.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users