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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.